The Ways a Cache Turns On You
Last timeWhere to Put It
Adding a cache adds a component that can fail, a dependence on it succeeding, and a crowd that arrives all at once the moment a popular answer expires.
Everything so far has been an argument for caching. This lesson is the other
side, and it matters more than the arguments in favour, because the failures a
cache introduces are the kind that arrive all at once rather than gradually.
The store can no longer serve
Start with the consequence that is easiest to miss. A service with a ninety-five
percent hit rate sends one read in twenty to the store, so the store is sized,
provisioned and budgeted for a twentieth of the traffic. That is the point. But
it means the cache has stopped being an improvement and become a structural
part. Remove it and the store receives twenty times what it can handle.
- how many times more load the store receives than it is used to
- the hit rate after whatever went wrong
- the hit rate the store was sized against
- the share of reads now reaching the store
- the share it was provisioned for, which is usually small enough to make the ratio alarming
This is why restarting a caching tier is not a routine operation, and why
"we can just turn the cache off" is almost never true in a system that has had a
cache for a year.
The lesson stops here
6 more paragraphs to go
You have read the opening. The rest of the argument, the problems that check whether it landed, and the lines worth keeping at the end all come with a plan.
The first lesson of every course in the library reads the whole way through, free, so you can see exactly what the rest of them are.
See the planThe contentsThis is the reading half
Starting the course gives you your own copy of it. Every idea on every page has problems standing under it, marked with a reason rather than a tick, and any sentence you do not believe can be opened and argued with. None of that can happen on a page nobody owns.
The contents