Three seconds down to 200 milliseconds is almost never the same endpoint going faster. It is a different endpoint.
The slow version answered the question honestly: it asked several carriers for live shipping rates, waited on the slowest one, and returned a fresh aggregate. No single call was broken. The latency was the design, because the response could not exist until every upstream had answered.
The fast version skips that work entirely. Rates get pulled on a schedule, normalized into one internal shape, and stored with a freshness stamp. The request reads a precomputed row. 200ms is a cache read wearing an API's clothes.
What you buy with that is a new obligation.
You now owe the caller a freshness contract: how stale a quote may be, which operations may use a stale one (showing options during checkout), and which must force a live call (buying a label, charging the customer).
You also owe yourself a visible failure mode for when the background job falls behind. Serving yesterday's prices quietly is worse than being slow, because nothing errors.
So the honest version of the claim goes like this. I did not remove three seconds. I moved them off the request path onto a job nobody is waiting on, and I paid for it with staleness I had to make explicit in the data model.
Most latency work is that trade rather than a clever optimization. Treat it as a product decision and the engineering gets simple.
I write up more of these mechanics on my blog: https://polycratia.com/c/bafb9eaf
If you have made this swap, I'd like to know where you drew the line between a cached quote and a live one...