Going from 3 seconds to 200ms is usually relocation, not optimization.
Nothing in the hot path got faster. The work moved out of it.
The endpoints I've seen sitting at multi-second latency rarely have one slow line. They have a response assembled at read time out of things that live somewhere else: a catalog record in one place, availability in another, delivery rates fetched live from several carriers, each call a network round trip with its own timeout budget. Add them up and 3 seconds stops looking like a bug: it's the honest cost of what the handler gets asked to do on every request.
Caching the whole response doesn't save you, because the cache key is usually per user or per destination, and the hit rate collapses exactly when traffic gets real.
What works is splitting the payload by how often it changes. The stable part (normalized catalog data and rate tables, plus anything derived from an ingest you already control) gets computed when the data lands, stored in the shape the endpoint returns. The volatile part shrinks to one indexed read. The handler stops computing and starts looking up.
The trade-off is real: the moment you precompute, you own invalidation. You need a deterministic recompute path, and you need a way to detect drift between the materialized view and the source of truth. Without that you've traded slow-and-correct for fast-and-quietly-wrong, which is a much worse failure mode in anything touching money or delivery promises.
I've written more on where these read paths break in production over on my blog: https://polycratia.com/c/a6fc8858
Last time you cut an endpoint's latency by an order of magnitude, you probably moved the work rather than made it faster, and gave up something to move it...