Your API can be slow while every query runs in single-digit milliseconds. The time is not in your code at all. It sits in everyone else's.
Most endpoints in payments, compliance and commerce are aggregators. A checkout call fans out to a payment provider. An onboarding call waits on a verification provider. A shipping call asks several carriers for rates. Each one is a network hop into infrastructure you do not own and cannot profile.
The mechanics are unforgiving. Call three partners in sequence from one handler and its tail latency is not the average of theirs: it is the sum of their worst cases. One provider sliding from 200ms to four seconds moves your p99 while your database dashboard stays flat and green. Put a retry policy on top of that and you have doubled the exposure instead of hiding it.
What I do about it: every outbound call gets an explicit time budget rather than a default timeout, and I decide up front which calls are allowed to block a response at all. The rest goes behind a queue or a cached last-known-good value. Carrier rates and verification results tolerate staleness far better than users tolerate a spinner.
Then instrument the gap. Total request time minus your own work is time spent waiting on third parties, and that one number tells you whether optimizing SQL will change anything.
I write up more of these production trade-offs here: https://polycratia.com/c/8bb3532d
If you run aggregating endpoints: do you degrade to a partial response when a provider slows down, or hold the request and hope it answers?