How to get caching layers right
This is one of those topics that looks small until it costs you something. The short answer to caching layers is that it is mostly a sequence of small decisions, not one big one.
Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. It is the sort of thing that looks like polish right up until it costs you an enquiry.
What is actually at stake
Caching is easy until something has to be invalidated. This is the sort of thing that compounds, quietly, in both directions. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.
The steps
- Establish what you have today before changing anything
- Cache close to where the cost is, not everywhere
- A stale cache with no expiry is a future incident
- Write down the decision so the next person does not re-litigate it
A stale cache with no expiry is a future incident. The cost of getting this wrong is rarely visible on the day it happens. If two people in the business would answer this differently, that gap is the actual problem.
What to do next
What this looks like day to day
The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. Three things worth confirming about caching layers before you move on:
- Someone can say what the current setup is without going to look
- Cache close to where the cost is, not everywhere — and you know whether that is true here
- There is a way to tell whether the last change to this helped
If you are not sure where your systems currently stand on this, it takes us about an hour to find out.