Follow a Slow Request
One checkout request at 2,430 ms. Every service returned 200 and no dashboard is red. Peel the request apart until the time is accounted for, then choose what to do about it.
A customer reports that checkout "takes forever". One request is captured end to end: POST /checkout, 2,430 ms. Nothing is broken — every service returns 200. Peel the request apart layer by layer until the time is accounted for.
What the user experienced. Every span below is part of this number; the job is to find which part you can actually change.
Everything before your code runs. Real, but not where the 2.4 seconds went.
Routing, auth token validation, rate-limit check. Cheap, and it stayed cheap under load.
Where the request actually lives. Note that the API's own CPU work is a rounding error — almost all of this is waiting on something else.
Open every layer and account for the 2,430 ms before revealing the findings. The question to hold onto: which of these could you change, and which belongs to someone else?
Now optimize it
§161 — the diagnosis was the hard part, but choosing the fix is where most teams still lose.
Five plausible fixes. Four of them are things real teams ship in this situation. Only one addresses what the trace actually showed — and one of the others is worth doing anyway, for reasons that have nothing to do with this incident.