Catalog
affaan-m/latency-critical-systems

affaan-m

latency-critical-systems

Optimize and verify latency-sensitive systems — realtime dashboards, market data feeds, streaming agents, execution gateways, queues, and caches — by tracking p50/p95/p99 latency, freshness age, and queue depth, mapping hot paths, and running live readbacks. Use when p95 latency, throughput, or data freshness matters.

NewUpdated Sep 27, 2026

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.
Files1
1 files · 1.0 KB

Select a file to preview

Overall Score

72/100

Grade

B

Good

Grades are signals, not a certification. Always review a skill yourself before use.

Safety

82

Quality

68

Clarity

78

Completeness

58

Summary

This skill guides agents to optimize and verify latency-critical systems by tracking p50/p95/p99 latency, freshness, queue depth, and identifying hot paths. It provides a structured methodology for measuring performance across system segments (API, queue, cache, client, browser) and applying targeted optimizations, with explicit guardrails against dropping validation, hiding stale data, or running live orders.

Detected Capabilities

file readfile writecode editingbash command executiongrep pattern matchingglob file globbing

Trigger Keywords

Phrases that agents use to match this skill to user intent.

optimize p95 latencyrealtime data pipelinemarket data freshnessqueue depth monitoringexecution gateway tuningstreaming system measurementhotpath analysiscache coherency verificationlive readback validationorder execution latency

Risk Signals

INFO

Skill mentions market data, HFT infrastructure, orderbooks, VWAP, and execution gateways

Description, Verification section
INFO

Guardrail explicitly prohibits live orders and customer-impacting deploys without approval gate

Guardrails section
INFO

Guardrail requires secrets and private payloads be kept out of logs and benchmarks

Guardrails section

Use Cases

  • {"use_case": "Optimize p95/p99 latency in real-time data pipelines (market feeds, trading gateways) by mapping hot paths and identifying optimization priorities"}
  • {"use_case": "Verify freshness age and stale-data behavior in streaming systems before deploying to production"}
  • {"use_case": "Measure and reduce queue depth and backpressure in event-driven architectures"}
  • {"use_case": "Diagnose performance bottlenecks in multi-segment systems (API → ingest → queue → cache → edge → client)"}
  • {"use_case": "Run live readbacks to verify deployed surfaces meet latency, freshness, and correctness targets under load"}
  • {"use_case": "Design canary validation for stale data, degraded providers, and cache coherency before go-live"}

Quality Notes

  • Strength: Clear methodology with numbered optimization order (6 steps) and explicit step-by-step hot path mapping guidance
  • Strength: Comprehensive metric taxonomy (p50/p95/p99, throughput, freshness, queue depth, cache hit rate) prevents vague 'speed' optimizations
  • Strength: Explicit guardrails address domain-specific risks (dropping validation, stale data, live orders) which could otherwise cause financial or data integrity harm
  • Strength: Well-structured sections with practical examples (hot path diagram, verification checklist)
  • Weakness: Limited concrete implementation examples — does not show code snippets, measurement tools (e.g., Prometheus queries, timing libraries, load testing patterns), or monitoring setup examples
  • Weakness: No explicit error handling or recovery guidance for measurement failures or live system failures
  • Weakness: Verification section lists what to check but not how to automate or script the readbacks — measurement methodology is conceptual rather than prescriptive
  • Weakness: No discussion of measurement overhead or observability cost, which is critical for latency-sensitive systems
  • Weakness: Does not specify which file types or code patterns the skill applies to (languages, frameworks, deployment targets)
  • Weakness: Caching and batching subsections (steps 2–3) lack specific architectural patterns or tradeoff guidance
Model: claude-haiku-4-5-20251001Analyzed: Sep 27, 2026

Reviews

Add this skill to your library to leave a review.

No reviews yet

Be the first to share your experience.

Version History

  1. v3.0

    Contract changed: description

    ✦ AIExpanded activation scope to include throughput and deeper latency metrics: p50, p95, p99 percentiles, freshness age, queue depth, hot-path mapping, and live readbacks.

    triggering2026-09-27

    LATEST
  2. v2.0

    Contract changed: description

    ✦ AIDescription expanded with repeated emphasis on p95 latency and data freshness; license added as MIT.

    triggeringlicense2026-09-09

    View This Version
  3. v1.1

    Content updated

    ✦ AINo behavioral changes detected.

    2026-07-14

    View This Version
  4. v1.0

    2026-05-25

    View This VersionInitial version

Use affaan-m/latency-critical-systems in your dev environment

Command Palette

Search for a command to run...