Caching Strategies

Knowing that a cache pays off is the easy part. The real design work is deciding how data gets into the cache and how it stays correct when the data changes. There are a few common patterns, and the one you pick decides what happens on every read and every write, and what you could lose if something crashes.

Imagine you answer questions for a company, and you keep a notebook on your desk with answers you have looked up before. The filing room down the hall holds the real records and is the source of truth. Each pattern is a different habit for using the notebook.

• -Cache-aside: you check the notebook. If the answer is missing you walk to the filing room, then copy the answer into the notebook before replying. You manage the notebook yourself.
• -Read-through: the same, except a clerk stands between you and both places. You only ever ask the clerk, who checks the notebook and fetches from the filing room for you.
• -Write-through: when an answer changes you update the filing room and the notebook together, and only then say done.
• -Write-behind: you update the notebook straight away and promise to update the filing room later, in a batch. It is fast, but if the notebook is lost before the batch is carried over, the change is lost.
• -Write-around: you update the filing room only and leave the notebook alone, so it is not filled with answers nobody asks for again.

Cache-aside, also called lazy loading, is the most common pattern because it is simple and fails gently. On a read, the application looks in the cache. On a hit it returns the value. On a miss it reads the database, stores the value in the cache with a time-to-live, and returns it. On a write, it updates the database and then removes the cached copy, so the next read refills it with fresh data. If the cache goes down, the application still works, only more slowly, because the database remains the source of truth.

The diagram shows the read path: the application asks the cache first and goes to the database only on a miss.

There is one subtle trap. Suppose a reader misses and fetches the old value from the database. Before it can store that value in the cache, a writer updates the database and deletes the cached key. The reader then stores the old value it fetched, and the cache now holds stale data until its time-to-live runs out. This is rare, which is part of why cache-aside is so widely used, but it is the reason every cached value should have a time-to-live as a safety net.

In write-through, every write goes to the cache and the database together before the caller is told it succeeded. The cache is never stale, but each write pays for both, so writes are as slow as the database. In write-behind (also called write-back), the write goes to the cache only, and the cache saves it to the database a moment later, often combining many writes into one. Writes feel very fast, but for a short window the only copy of the data is in the cache, and a crash inside that window loses it.

• -Read-heavy data that can be a little stale: cache-aside with a time-to-live (product pages, profiles).
• -The cache must never be stale, and you can afford slower writes: write-through (a user's settings, read straight after being saved).
• -Write-heavy data where a small loss window is acceptable: write-behind (counters such as view counts, activity metrics).
• -Data written once and rarely read: write-around, so it does not push hot items out of the cache.
• -Money, orders, or anything that must never be lost: never write-behind.

A strong interview answer names the pattern and its failure mode in one breath, for example: I would use cache-aside with a 5-minute time-to-live. If the cache dies we fall back to the database, and a stale entry lives for at most five minutes.

The Wiki card below compares the patterns side by side, with when to use each: