When caching layers is worth the effort

Teams tend to reach for this after something has already gone wrong. Caching layers is not free, and pretending otherwise leads to bad decisions.

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. Check it against what you would want a competitor's site to get wrong.

When it is worth it

Caching is easy until something has to be invalidated. In practice this is a scheduling problem more than a technical one. Write the reasoning down alongside the decision, because the reasoning is what changes first.

When it is not

If nothing downstream depends on it and nobody is complaining, it can wait. The reasoning matters more than the rule, because the rule has exceptions.

How to decide

A stale cache with no expiry is a future incident. Where this goes wrong is almost never a lack of knowledge. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

How to tell if yours is fine

Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. Three things worth confirming about caching layers before you move on:

• Someone can say what the current setup is without going to look
• A stale cache with no expiry is a future incident — and you know whether that is true here
• There is a way to tell whether the last change to this helped

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.