A 3-second response is usually not slow work. It is a failure that succeeded on the third try.
Latency that lands on a round number is rarely computation. Computation is messy, and it scales with how much data you throw at it. Round numbers come out of configuration: a backoff curve, a retry count, a client default nobody picked.
The mechanics are simple and invisible. Your handler calls a provider (a card gateway, a verification vendor, a chain node). The first attempt dies on a connection reset or a 502. The HTTP client, following defaults it inherited, waits half a second and retries, waits a second and retries. The third attempt works. The handler returns 200.
Nothing lands in the logs as an error, because nothing finally failed. So the error rate looks clean and the endpoint looks slow. You go profile the database, and the database is innocent.
What fixes this is not a faster retry: it is making the retry budget visible.
One deadline per inbound request, passed down to every outbound call, so the attempts can't add up to more than the caller will wait.
Retries only where repetition is safe: idempotency-keyed, not "probably fine".
Attempt count as a metric on every provider call, so a rising retry rate shows up before it turns into latency.
In payment and verification flows, a success that took three seconds carries more information than a clean failure. The failure tells you something broke. The slow success tells you something is breaking, repeatedly, and your instrumentation agreed to hide it.
I write up more of these production patterns on my blog: https://polycratia.com/c/e6ef3984
Worth knowing where retries live in your system today: a client-library detail, or a number you can alert on...