Classify and fix: matching bottleneck families to remedies

Two engineers look at the same flame graph. One sees “GC is hot” and rewrites the allocator. The other sees “GC is hot because of a bulk upstream payload” and rolls back one deploy. The first spends a week; the second spends 35 minutes. The difference is classification — naming the bottleneck family before touching the code.

The eight bottleneck families

The seven pieces of this chapter map to a small vocabulary of bottleneck families. When you classify a hotspot correctly, the fix set follows immediately.

Amdahl before you code

Amdahl’s law: if fraction f of execution time is spent in the hotspot, the maximum speedup from fixing it is 1 / (1 - f).

If the hotspot is 40% of CPU (f = 0.4), the best possible speedup is 1 / 0.6 = 1.67x. If your SLO needs a 3x improvement, this is the wrong hotspot. Return to step 2 and profile again.

This calculation takes 30 seconds. It prevents weeks of work on the wrong target.

Example: A checkout service has p99 = 800 ms and a target of under 200 ms. The profile shows:

• json.Marshal: 28% CPU
• runtime.scanobject: 22% CPU
• pgx.Query: 18% CPU (via trace spans — actually I/O)

Amdahl on Marshal alone: 1 / (1 - 0.28) = 1.39x. That brings 800 ms to ~575 ms — still above target. Amdahl on Marshal + scanobject combined (50%): 1 / 0.5 = 2x. That brings to ~400 ms — still above target. Adding the I/O path (68% total): 1 / 0.32 = 3.1x. That brings to ~258 ms — close.

Real root cause: all three hot frames share an upstream that suddenly returns 10x more data. Fix the upstream; all three frames shrink together. Total gain: 6x. The Amdahl calculation made it clear that fixing any single family in isolation was insufficient.

Cross-layer compounding

Real bottlenecks rarely sit in one layer. A slow checkout page might be 30% JS bundle parse on the client, 20% N+1 queries in the backend, 15% GC allocation pressure, and 35% backend compute. Fixing any one layer in isolation gives only Amdahl-bounded wins on the total.

The compound effect is the real win. Two engineers working in parallel — one on bundle, one on queries and GC — each delivering a 2x improvement, give a combined 4x on the headline metric. Without cross-layer reasoning, the conversation stalls: “we already optimised our part.”

The chapter’s classification vocabulary lets engineers from frontend, backend, and infra describe their bottleneck in a way the other layers understand. Without the shared vocabulary, “the backend is slow” and “no, the frontend is slow” is the whole conversation.