Data performance

Latency Critical Systems

Use this skill when the user cares about realtime behavior, hot paths, streaming freshness, or execution speed. This includes HFT-like infrastructure, but the skill is engineering-focused. It does not authorize live trading or financial advice.

Split The Metrics

Do not collapse everything into "fast." Track:

• p50, p95, and p99 latency;
• throughput;
• freshness age;
• queue depth;
• cache hit rate;
• provider/API response time;
• browser render time;
• correctness under load;
• failure and retry behavior.

Map The Hot Path

Write the path from user/event to final visible state:

source event -> provider API -> ingest worker -> queue -> cache -> edge route
-> client stream -> browser render -> user-visible state

Then measure each segment separately.

Optimization Order

1. Remove unnecessary round trips.
2. Cache stable reads with freshness metadata.
3. Batch small calls and writes.
4. Move compute closer to the data or the user.
5. Split hot and cold paths.
6. Apply backpressure before queues grow unbounded.
7. Use streaming only when it improves freshness or user experience.
8. Add canaries for stale data, degraded providers, and bad cache state.

Verification

Use live readbacks when a deployed surface exists:

• HTTP timing and response headers;
• provider freshness timestamp;
• queue or job state;
• edge/cache state;
• browser verification for actual UI freshness;
• logs around retries and degraded mode.

For market-data or execution-adjacent paths, also verify orderbook age, VWAP assumptions, provider status, and kill-switch behavior before calling the path ready.

Guardrails

• Do not optimize latency by dropping required validation.
• Do not hide stale data behind fast cache hits.
• Do not claim millisecond behavior from client labels without measurement.
• Do not run live orders, destructive migrations, or customer-impacting deploys without an explicit approval gate.
• Keep secrets and private payloads out of logs and benchmark artifacts.

---

Data Throughput Accelerator

Use this skill when the bottleneck is moving, transforming, or saving lots of data. The goal is not just speed. The goal is faster correct data landing in the right place with proof.

First Distinction

Separate these before optimizing:

• source extraction speed;
• network transfer speed;
• warehouse/load speed;
• transform speed;
• serving-table freshness;
• live tail growth while the job runs.

A pipeline can be "fast" and still appear behind if new data arrives faster than the final catch-up window.

Fast Path Heuristics

• Move compute to where the data already is.
• Prefer warehouse-native scans, joins, and appends for large landed files.
• Use manifests or checkpoints so completed files/partitions are skipped.
• Use partitioning and clustering that match the read and append pattern.
• Batch small files, requests, and writes.
• Make writes idempotent through unique keys, manifests, or replaceable staging.
• Keep raw, derived, and serving tables separately accountable.

Workflow

1. Read the current source, target, and manifest contracts.
2. Measure backlog: external files, manifest rows, raw rows, derived rows, min/max timestamps, and unprocessed counts.
3. Run a safe catch-up or sample benchmark.
4. Compare variants: batch size, worker count, warehouse SQL, file grouping, staging shape, and manifest update method.
5. Promote only the fastest path that keeps counts and timestamps coherent.
6. Codify the path as a CLI, scheduled job, workflow, or runbook.
7. Rerun final accounting after the codified path executes.

Accounting Output

Use a hard accounting block:

Data throughput result:
- Source files discovered: 294
- Files processed this run: 294
- Raw rows added: 9,683,598
- Derived rows added: 8,917,585
- Remaining tail: 24 files at readback time
- Runtime: 38.7s
- Correctness gate: manifest counts and table max timestamps match

Guardrails

• Do not delete raw data to make a metric look better.
• Do not skip failed files silently.
• Do not mix historical backfill status with live-tail freshness.
• Do not call a pipeline complete until the target tables and manifest agree.
• For finance, healthcare, regulated, or customer-impacting data, preserve replay evidence and approval gates.