Cutting an API response from 3 seconds to 200ms is accounting, not optimization. The work rarely got faster. It got relocated, and something has to pay for it now.
Most of those wins I've shipped landed in one of three places.
Precomputed before the request: a projection, a cached aggregate, a stored balance instead of a live sum over the ledger. Fast, and now I own an invalidation story. The endpoint stops being slow and starts being occasionally wrong.
Deferred after the response: the carrier rate call, the verification provider, the on-chain lookup all go to a queue, and the caller gets an accepted state. Fast, and now there is a second path that can fail after the user is gone, so it needs retries, idempotency, and a place to record the jobs that did not finish.
Deleted from the contract: the field nobody reads, the total that nothing paginates on. That one is genuinely free, and it is the one most often skipped, because it means arguing with product instead of with code.
So before shipping the 200ms version I write down the staleness bound rather than the latency: how wrong this response is allowed to be, and for how long, plus who reconciles the deferred path when it stalls.
In money systems that is where the bug shows up eventually. Not in the fast endpoint. In the thing that was supposed to catch up and quietly didn't, until a balance or a payout doesn't match.
A 15x improvement is a trade you accepted on behalf of the callers downstream. Worth being able to say which one.
If you've made that cut, I'd want to know what staleness you agreed to, and whether anyone is checking it.