The one number that matters
Your hit rate is the fraction of reads served from the cache, and it is the single number telling you whether the cache is doing anything at all.
The arithmetic around it is unintuitive, because that gap causes real capacity mistakes.
Latency first. A cache hit in the same data centre costs about half a millisecond, and an indexed database read costs 5 to 10, so every hit is a tenfold win on its own.
At a 90 percent hit rate your average read lands around a millisecond, dominated by the misses even though they are rare.
The arithmetic people get wrong
The load arithmetic is where people slip. Your hit rate decides what fraction of traffic reaches your database, so the number that matters is the miss rate.
Going from 90 percent hits to 99 sounds like a 10 percent improvement. It is a tenfold one, because database traffic falls from a tenth of your reads to a hundredth.
Run backwards it gets frightening. If your database is sized for the misses at 99 percent, a sag to 90 multiplies its load by ten instantly.
Caches rarely fail by turning off, because it is rarely by turning off. They fail by their hit rate dropping, after a flush, a key schema change, or a wave of evictions, and your database inherits the difference.
Hit rate deserves an objective and an alert, not a vanity number. Watch it per key prefix, because a healthy 95 percent overall can hide one endpoint missing constantly.
Plan database capacity for the hit rate you can survive, not the one you see on a good day. A reasonable rule: it should handle three to five times your steady-state miss traffic without falling over.
Worked example
Sam runs the API platform at a news site doing 50,000 reads per second at peak. Redis serves 98 percent of them, so Postgres sees a comfortable 1,000 queries per second. On an election night, an engineer ships a change that adds a locale field to the cache key, and every existing key stops matching. Hit rate drops from 98 to 31 percent in under a minute, and Postgres, sized for about 4,000 queries per second, takes 34,000. Connections exhaust, latency goes vertical, and the site is effectively down for 11 minutes until the deploy is rolled back. The postmortem action items: alert when hit rate falls 5 points below baseline, canary cache-key changes on 1 percent of traffic, and dual-read old and new key formats during migrations.