A compliance operator told me the approve button felt slow. I checked the database first, the way you do. Every query in that request came back in single-digit milliseconds.
The time was going somewhere after the write. Approving a verification also notified the user (push, email, messenger), and the handler did all of it inline, one provider call after the next, inside the request. The database was not the problem. The request was making network round trips into other people's systems before it answered.
The latency was the smaller half of it: the write had already committed. When one notification provider hung, the operator saw a failed action sitting on top of a state change that had actually happened. So they clicked approve again.
Notifications stay out of the request path now. The handler writes the state change and an outbox row in the same transaction, returns, and a worker does the fan-out with its own retries and its own idempotency key per channel. The endpoint responds at the speed of the database, which is what the operator assumed it did all along.
In a slow endpoint I no longer start with a query plan. I start with one question: what is this request doing that the caller never asked for? Notification fan-out, audit shipping, cache warming, analytics events, that work collects inside handlers because the handler is where it was easiest to add.
When you last chased API latency, maybe it was your own code, or maybe an external call you were politely waiting on...