How We Reduced a Client's API Latency by 80%
A deep dive into caching strategies, database query optimisation, and edge computing for high-traffic endpoints under real load.
Measure before you rewrite
The client came to us with a dashboard API sitting at roughly 1.2s p95. Stakeholders wanted a rewrite. We started with traces instead. OpenTelemetry showed three dominant costs: an N+1 ORM pattern, a synchronous enrichment call to a partner API, and zero caching on mostly-static catalog data.
That triage mattered. Rewrites feel productive; eliminating unnecessary work is usually faster. We set a success metric — p95 under 250ms for the authenticated read path — and refused to celebrate micro-optimisations that did not move that number.
Query shapes and indexes that match access
The N+1 vanished after we introduced a single SQL query with targeted joins and a covering index for the filter set the UI actually used. EXPLAIN plans before and after became part of the PR template for this service.
We also stopped selecting wide rows for list endpoints. Returning only the columns the card UI needed cut I/O and serialisation time more than any JSON compressor ever did.
Caching with explicit invalidation
Redis cached catalog and permission snapshots with short TTLs plus event-driven invalidation on writes. The mistake teams make is caching without a coherence story — we documented every cache key, owner, and bust path.
For personalised payloads, we cached partial fragments and assembled at the edge of the API. Full-response caching looked simpler but collapsed under permission variance across tenants.
Edge and async where it counts
Partner enrichment moved behind an async job with a stale-while-revalidate response for the dashboard shell. Users saw useful data immediately; enrichment caught up within seconds.
Read-heavy geo traffic benefited from edge caching of public fragments. Authenticated mutations stayed regional. The 80% latency win was not one trick — it was removing wait time the product never needed on the critical path.
Alex Thompson
Backend Engineer
Backend engineer focused on performance, Postgres, and TypeScript platforms at scale.
