latency-critical-systems

Latency Critical Systems (Laravel)

Engineering approach for latency-sensitive Laravel paths: realtime dashboards, streaming, ingest workers, queues, caches, and execution gateways where p95 latency and freshness matter. This skill is engineering-focused; it does not authorize live trading or financial advice.

Constraints

• Apply @rules/sql/optimalize.mdc for every query on the hot path (N+1, eager loading, index usage, batching)
• Apply @rules/laravel/laravel.mdc for framework-level structure and caching choices
• Apply @rules/laravel/queue-debouncing.mdc when smoothing bursty queue work
• Measure, do not guess — every claim about latency must come from a real readback.
• Never trade correctness for speed (see Guardrails).

Use when

• A page, API route, broadcast, or dashboard must hit a latency target (p95/p99).
• Queue lag, cache staleness, or freshness age is a visible problem.
• Streaming / websocket freshness or execution-gateway timing is in scope.
• You are deciding where to cache, batch, replicate, or move compute.

1. Split the metrics

Do not collapse everything into "fast." Track separately:

• p50, p95, p99 latency (one slow tail dominates user perception);
• throughput (requests/jobs per second);
• freshness age (how old the displayed data is);
• queue depth and queue wait time;
• cache hit rate;
• provider/external API response time;
• browser render time;
• correctness under load;
• failure and retry behavior.

Capture them with real tools: response timing headers, Horizon metrics, Redis INFO/MONITOR, slow-query log, and Laravel Telescope for per-request timing breakdowns.

2. Map the hot path

Write the path from event to visible state, then measure each segment:

source event -> provider API -> ingest job -> queue (Redis/Horizon) -> cache (Redis)
-> Octane worker / route -> broadcast (websocket) -> Livewire/browser render -> user

For each segment record where time goes. The bottleneck is usually one segment, not the whole chain — instrument before optimizing.