Three seconds down to 200 milliseconds, and almost none of that came from faster code.
The endpoint was a product listing that assembled its own answer on every read: catalog data, availability, and live delivery rates fanned out to several carriers. Each piece was fine on its own. Serially, inside one request, they were not.
So I moved the work instead of optimizing it.
Carrier rates turned into precomputed quotes, refreshed on their own schedule and keyed by the few dimensions that actually move a price. Derived fields that used to be recalculated per request got materialized at write time. The response shrank to what the caller renders, not what the ORM was happy to serialize. What was left in the request path was a lookup.
The part nobody puts in the before/after screenshot: you just bought staleness. A precomputed rate can be wrong by the time you see it, and a materialized field can drift from its source. That has to be designed and not discovered: explicit freshness windows, a path that flags a stale or missing quote instead of quietly serving it, and invalidation that rides along with the write rather than a cron job hoping to catch up.
200ms is not a performance achievement. It is what follows from deciding what a request is allowed to do.
I went deeper on where this trade-off breaks over here: https://polycratia.com/c/7f471073
I'd be curious where you draw your own line between computing on read and materializing on write...