A 99% cache hit rate means your database has never been load tested
at real traffic.
It has only ever seen 1% of it.
Wikimedia published the postmortem. Their hit ratio fell while demand
stayed flat, and the origin took five times its normal load. Nothing
else changed. The cache just stopped absorbing.
Which means the number on your dashboard is not a performance metric.
It is the size of your outage.
I went through primary sources on caching for a video recently, and
that reframe was the one that stuck. A cache is a second copy of your
data. Every hard question after that is about the copy, not the cache.
Then there is the cost, which most advice treats as settled. Memory
is cheap, databases are expensive, therefore cache. I priced it out
in August 2026. A cache node runs about 21% cheaper than a comparable
read replica per gigabyte. Not an order of magnitude. Twenty-one
percent.
A cache pays for the traffic it absorbs and nothing else. That is the
entire business case.
The patterns everyone teaches do not survive checking either.
Write-through has three incompatible vendor definitions. AWS lists
"never stale" as an advantage. Microsoft ships a repair function
because the cache write can fail after the commit. Write-around, the
fourth column in every caching-patterns table online, appears in none
of the nine primary sources I checked.
And there is one test almost nobody runs. It is a single sentence in
AWS's own guidance: run load tests with caches disabled.
Full breakdown, 65 minutes, chaptered, every claim tied to a primary
source: https://youtu.be/ETvLl-8bPbo
What is inside the box, the six layers a request passes through, the
write patterns, the failure modes, and the cost math.
Top comments (0)