Cutting API Latency 80% — A Profiling Story

TL;DR

We cut latency on three sourcing APIs by 80%. The wins came from profiling first, then fixing a small number of hot queries and adding targeted caching — not from rewriting everything.

The problem

Our sourcing module had three core APIs that buyers hit constantly. Under normal load they were fine, but during peak sourcing activity the response times spiked, dashboards dragged, and users startedRefresh to get data.

What we assumed vs. what the profiler said

The team assumed the issue was database load at the connection-pool level. The profiler told a different story:

• One endpoint was running N+1 queries inside a loop that looked innocent.
• Another was serializing large ActiveRecord objects we never needed.
• A third was repeatedly computing an aggregate that rarely changed.

What we changed

1. Killed the N+1 with a single includes / preload pass.
2. Replaced full-object serialization with a lean SQL select of only the columns the API returned.
3. Cached the aggregate in Redis with a short TTL keyed by the relevant scope.
4. Added query-count logging to CI so future PRs couldn't silently reintroduce the same pattern.

The result

• 80% latency reduction on the three APIs.
• No infrastructure cost increase.
• The biggest surprise: the fix was a few hundred lines, not a rewrite.

What I learned

The expensive code is usually not where you think it is. Profile before you optimize, measure after, and make the cheap wins impossible to regress.