Three seconds down to 200 milliseconds, and almost none of that came from making the query faster.
The endpoint returned a user's balance, and it computed that balance the honest way: read every ledger entry for the account, sum them, apply holds. Correct and auditable, and linear in account age. So the oldest accounts were the slowest, which is backwards, since those are the users you least want to keep waiting.
The fix was to stop computing a value that only changes when something writes it. The balance became a row updated in the same transaction as the ledger entry that moved it. One row read, no aggregation, no cache in front, no invalidation to get wrong.
Most of the work lands somewhere else: proving the stored number still equals the derived one. So the ledger stays the source of truth, the maintained balance is an optimization, and a reconciliation job recomputes from entries and alerts on drift instead of quietly serving a wrong figure. Drift you detect is an incident. Drift you miss is a dispute months later.
The rule I keep coming back to: when a read is slow, ask first whether it is re-deriving something a write already knew. Indexes make derivation cheaper. They do not make it unnecessary.
So I'd want to know where your authoritative balance lives, derived on read, or maintained on write with a checker sitting behind it...