PROJECT / SAMPLE
Scaling wasn't the problem. Waiting was.
Request-path profiling found latency across queries, serialization, cache behavior, and sequential service calls—without a rewrite.
- Date
- 2026-01
- Type
- software / reliability
- Status
- fictional fixture
- Published
- prototype only
Problem
An API slowed sharply under moderate load. The expected response was more compute, but the request path had never been measured end to end.
Constraints
- Public API behavior had to remain compatible.
- The platform could not pause feature delivery for a rewrite.
- Changes needed isolated performance evidence.
Observed
- Several network dependencies ran sequentially despite being independent.
- Serialization repeated the same transformation at service boundaries.
- A high-cost query defeated the existing cache strategy.
Work
- Profiled the complete request path under representative load.
- Reworked query shape and cache ownership.
- Removed unnecessary service-boundary serialization.
- Parallelized independent network dependencies.
- Added performance budgets to the release path.
Decisions
- Measure queueing and waiting before adding compute.
- Optimize the slow path without changing the public contract.
- Keep a regression workload next to the code.
Result / SAMPLE
The existing architecture handled the expected load with substantially lower latency and less compute.
- p95 latency: 2.8s → 240ms
- compute requirement −46%
- no rewrite
What we did not do
We did not scale out a request path dominated by avoidable waiting. More instances would have multiplied the inefficiency.
Technical index
profiling / databases / caching / performance testing