Cache-aside vs write-through vs write-back: an interactive simulator

Caching reads is the easy part; the design question is what happens on a write. Cache-aside writes the database and deletes the cached copy. Write-through writes both together. Write-backwrites only the cache and flushes to the database later. Write-around writes only the database and lets the cached copy expire. They trade write latency, read hit ratio, database load, freshness and the risk of losing data.

The playground runs the same ten seconds of reads and writes through all four. Change the share of writes and how often write-back flushes, and compare the cards.

The four policies

What the playground shows

With 10% writes, cache-aside hits 78% of reads and write-through 87%, because write-through leaves the fresh value in the cache where cache-aside leaves a hole. Push writes to 50% and cache-aside’s hit ratio falls to 45% while write-through stays near 89%. Write-back answers writes in 1 ms and, flushing once a second, sends the database about half as many writes, since a hot key written ten times between flushes is flushed once; but when the cache node crashes, the 120 keys written since the last flush are gone, and with a 10 second flush, 643. Write-around keeps writes simple but serves old values: 57% of reads returned a value the database had since overwritten, each until the 5 second TTL expired it.

Choosing

• Default to cache-aside with delete-on-write and a TTL. It is simple, it never caches what nobody reads, and the TTL bounds the damage of any bug.
• Use write-through when data is read right after it is written, like a profile edit, and an extra cache write per update is cheap.
• Use write-back only where losing recent writes is acceptable or the cache itself is durable and replicated: counters, metrics, rate-limit state, game scores flushed periodically.
• Use write-around for data written in bulk and rarely read soon after, such as logs or ingestion pipelines.

Whatever the policy, delete rather than update cached values on writes from many writers: two concurrent writers can update the database in one order and the cache in the other, leaving the cache holding the older value with no TTL to rescue it. Deleting, and letting the next read refill, avoids most of that race. For a hot key, pair this with protection against a cache stampede on the refill.

Cache-aside and write-through in code

# cache-aside: the application owns the cache
def get_user(user_id):
    user = cache.get(f"user:{user_id}")
    if user is None:
        user = db.query_one("SELECT * FROM users WHERE id = %s", user_id)
        cache.set(f"user:{user_id}", user, ttl=300)       # fill on miss
    return user

def update_user(user_id, fields):
    db.execute("UPDATE users SET ... WHERE id = %s", user_id)
    cache.delete(f"user:{user_id}")                      # delete, don't set: avoids racing writers

# write-through: write both before acknowledging
def update_user_through(user_id, fields):
    user = db.execute_returning("UPDATE users SET ... WHERE id = %s RETURNING *", user_id)
    cache.set(f"user:{user_id}", user, ttl=300)

In a system design interview

Say the policy per kind of data, and what happens when the cache dies: “Product pages use cache-aside with a 5 minute TTL and delete-on-update. Like counts are write-back: increments go to Redis and a job flushes them to the database every few seconds, and losing a few seconds of likes in a cache failure is acceptable. Sessions are written through, since they are read on the very next request.” Expect the follow-ups: consistency between cache and database, what a cold cache does to the database, and how invalidation reaches every cache node.

Read the guide to caching or cache invalidation, see LRU caches for what gets evicted, or watch a strong candidate design a distributed cache.

Questions people ask