The shipping rates endpoint took seconds to answer. Every query behind it ran in milliseconds.
I spent most of a day profiling the wrong layer.
The handler was not doing database work. It was asking several carriers for a quote (rates, available services, delivery windows), one call after another, sequentially. Postgres sat idle. The request was just waiting on networks I did not control.
The part I took longer to accept: on that endpoint there was no fast path for me to build. A carrier having a slow morning set the response time for every user who got as far as checkout, however clean my code was.
So I stopped treating outbound calls as an implementation detail and started treating them as the budget. Now, before the handler exists, I write down every external call it will make and what the endpoint is allowed to spend in total. Then: fan out concurrently instead of in sequence, give each call a timeout well under the endpoint budget, cache quotes keyed on normalized inputs, and return a partial answer that is explicitly labelled partial instead of holding the whole response hostage to the slowest participant.
A fast database buys you very little when the handler spends its life waiting on someone else's network. You cannot optimize a third party. You can only bound it, and decide in advance what the user sees once the bound gets hit.
I wrote more about these trade-offs here: https://polycratia.com/c/dd65261b
So when a third-party call blows your latency budget, the thing to settle early is what you return: stale, partial, or an error.