5 Caching Strategies

Caching strategy is really a choice about ownership. Which layer decides when data is loaded, when it is written, and how much staleness the system can tolerate? That matters more than the cache product itself. The read and write contract determines whether the cache reduces load or creates harder consistency bugs.

1. Cache-aside

Cache-aside is the default pattern in many applications because it keeps the cache optional. The application looks in the cache first. On a miss, it reads from the database, returns the result, and stores that result in the cache for later requests.

This works well for read-heavy workloads with a stable hot set. It is simple to reason about and avoids filling the cache with data nobody asks for. The downside is that the first request after expiry still pays full database latency. If many requests miss on the same key at once, they can stampede the database unless the application coalesces those misses or adds jitter to TTLs.

Use cache-aside when the application already owns read logic and can tolerate occasional misses.

2. Read-through

Read-through moves miss handling into the cache layer. The application asks the cache for a key and the cache itself loads the value from the backing store if the key is absent.

The main benefit is centralisation. Every caller sees the same loading behaviour, which can simplify application code and observability. The tradeoff is flexibility. The cache now needs to understand the backing data model, failure semantics, and serialisation rules. Read-through is strongest when the data source is stable and access patterns are predictable.

3. Write-through

With write-through, the application writes to the cache and the database as part of the same logical operation. If implemented correctly, later reads see fresh cached data immediately, which makes this pattern attractive when read-after-write behaviour matters.

The price is write latency. A write now touches two systems on the critical path, and failures need careful ordering. If the database write succeeds but the cache write fails, the system may serve stale data until eviction or repair. Teams usually address this with retries, explicit invalidation, or treating the database as the source of truth and rebuilding cache state after faults.

Write-through is a good fit when newly written data is likely to be read again soon and stale reads are costly.

4. Write-around

Write-around sends writes straight to the database and skips the cache. The cache is only populated later if a read actually needs that value.

This avoids cache pollution. Large write-heavy systems often generate many values that are created once and rarely read again. Caching all of them wastes memory and evicts hotter entries. The immediate tradeoff is the post-write miss. The first read after a write still has to fetch from the database, so this pattern is less suitable when the same object is almost always read immediately after mutation.

5. Write-back

Write-back, sometimes called write-behind, acknowledges the write after it reaches the cache and persists it to the database later. This gives the fastest apparent write latency and can batch database operations efficiently.

It also carries the highest operational risk. The cache is temporarily the only durable holder of new state, so a crash before flush can lose data unless the cache layer has its own durable log or recovery mechanism. Reordering can also appear during flush, which matters for counters, balances, and any workflow that depends on strict sequencing.

There is no universal winner. Cache-aside and write-around are common because they keep the database as the clear source of truth. Write-through is useful when freshness matters on the next read. Read-through helps when a platform team wants to centralise loading behaviour. Write-back is for specialised high-throughput paths, not for casual optimisation. The right strategy starts with data access patterns and failure tolerance, not with the cache technology.