Going from three seconds to 200ms is almost never the code getting faster. The work left the request.
The large wins of that shape I've shipped were relocations rather than optimizations. The work went to one of three places.
Write time. A balance you compute by summing a ledger on every read becomes a maintained row, updated in the same transaction as the entry that changes it.
Background. Outbound work (a provider lookup, a document render, a notification fan-out) moves behind a queue, and the response hands you a handle instead of a result.
The client contract. Pagination, narrower payloads, fewer embedded relations: the endpoint stops answering questions the client didn't ask.
What rarely makes the headline is that each of those buys latency with an invariant you now have to maintain. A maintained balance can disagree with its ledger. A queued job can fail after you already returned 200. A narrowed payload means the client makes a second call that your new number didn't count.
So the 200ms is real, and it describes a different system with a different failure mode, not a faster version of the old one.
In money systems I only take that trade when the derived value has a recompute path: a job that rebuilds it from the source of truth and reports the delta instead of quietly correcting it. If you can't prove the two agree, you didn't speed up a read. You probably created a second source of truth.
I write up more of these trade-offs, which reads may be stale, which must be computed, and how the proof is built, on my blog: https://polycratia.com/c/ebc53da3
Worth knowing which reads in your system are allowed to be stale, and who actually made that call...