Caching layers for small teams

This is one of those topics that looks small until it costs you something. Most advice about caching layers assumes a team that does not exist at your size. Here is the version that does not.

Most systems fail at the seams rather than inside any one component. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

What to keep

Caching is easy until something has to be invalidated. None of that requires a large budget, only a decision and someone to own it. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. The cost of getting this wrong is rarely visible on the day it happens.

How to approach it

A stale cache with no expiry is a future incident. There is a version of this that is over-engineered, and it is worth avoiding. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

How to tell if yours is fine

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
• Caching is easy until something has to be invalidated — 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.