Cache Write Strategies

Before choosing a write strategy, it helps to see how many caches a request already passes through. Each one is an opportunity and a place for stale data to hide.

Client — the browser holds responses according to cache headers and user actions. Cheap and close to the user, but harder for the origin to invalidate once a fresh response has been sent.

CDN — edge locations, covered in the CDN lesson.

Web server — a reverse proxy caching whole responses without waking your application at all.

Application — an in-process or shared cache (Redis) holding objects or query results. This is where you have the most control and where the strategies below apply.

Database — plan or result caches where the product provides them and, more importantly, the buffer pool holding hot pages in memory. Largely automatic.

Within the application layer there are two flavours worth separating. Caching at the query level keys on the query text, which is simple but brittle: any change to the underlying rows invalidates an unpredictable set of keys. Caching at the object level stores an assembled domain object, which is easier to reason about and to invalidate — you know exactly which object changed.