A shipping-rates endpoint answered in roughly three seconds, and the working assumption was that the carriers were just slow.
They were slow. Not three seconds slow.
So I put timing around every outbound call, and found two problems stacked on each other. The rate requests went out to the carriers one after another, so the endpoint cost the sum of all the integrations instead of the slowest one. Each request also opened a fresh HTTPS connection, new handshake and all, because the client was getting constructed per call. Next to that, the handler logic was a rounding error.
The fix was unglamorous: persistent sessions per carrier, with the fan-out running concurrently. On top of that a hard time budget across the whole set, so one degraded carrier returns no quote instead of holding checkout hostage.
The real cost was the weeks before. The slowness lived in conversations as a vendor problem, which is a comfortable story, and comfortable stories stop anyone from looking at the part that was mine to fix.
So now, on any endpoint that talks to third parties, outbound calls get their own timing from day one, measured separately from handler time. If I cannot say how many milliseconds went to waiting on someone else's network, I do not know where the latency went. I am guessing with extra steps.
I write up more of these production post-mortems here: https://polycratia.com/c/0a56a981
Your request path probably still waits in sequence somewhere for things it could be asking for at once...