What to ask your agency about caching layers
This is one of those topics that looks small until it costs you something. If you are briefing an agency or a freelancer on caching layers, these questions are worth asking early.
The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.
Questions worth asking
- Who will actually do this work, and have they done it before?
- How will we know afterwards whether it worked?
- What happens if it needs changing in a year?
- What are you assuming that we have not confirmed?
What a good answer sounds like
Caching is easy until something has to be invalidated. Getting it slightly wrong is survivable. Ignoring it entirely is not. It is the sort of thing that looks like polish right up until it costs you an enquiry.
A stale cache with no expiry is a future incident. It is worth being explicit about, because assumptions differ quietly. Budget a little time for it every quarter and it never becomes a project of its own.
In practice
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
- 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 any of that sounds like a description of your current setup, it is fixable.