Cache-aside, write-through and write-back

Who talks to the cache and when: the main ways to wire a cache to a database.

Knowing that a cache exists is not enough; you must decide who fills it and who updates it. Three patterns cover most designs. The differences are about who is responsible and what happens on a write, and they trade simplicity, freshness and durability against each other.

Cache-aside (also called lazy loading) is the default. The application checks the cache; on a miss it reads the database and writes the result into the cache itself. Writes go to the database and then delete or update the cache entry. The cache only contains what has been asked for, and if the cache dies the app keeps working against the database.

def get_restaurant(rid):
    key = f"restaurant:{rid}"
    data = cache.get(key)
    if data is not None:
        return data                 # hit
    data = db.query_restaurant(rid) # miss: go to the source
    cache.set(key, data, ttl=600)
    return data

def update_restaurant(rid, fields):
    db.update_restaurant(rid, fields)
    cache.delete(f"restaurant:{rid}")  # next read refills

Cache-aside: the application owns the logic (illustrative).

Write-through puts the cache in the write path: every write goes to the cache and the cache synchronously writes to the database before acknowledging. Reads are always fresh because the cache and database agree, but every write pays for both, and you cache data that may never be read. Write-back (write-behind) acknowledges the write once it is in the cache and flushes to the database later in batches. Writes become very fast, but if the cache node dies before flushing, those writes are lost.

Write-through versus write-back differ in when the database is updated.

Choosing a pattern

Step 1 of 3

Mostly reads, tolerates brief staleness

Cache-aside. Simple, resilient, and the cache holds only what is popular. Menus, profiles and product pages fit here.

Question 1

In cache-aside, who is responsible for filling the cache after a miss?

Question 2

What is the main risk of write-back caching?

Your turn

A view counter for videos is incremented 20,000 times per second. Which pattern would you use for it, and what loss would you accept?

Stuck? Think about how bad it is if the last two seconds of increments disappear.

What to remember

Cache-aside: the app reads the cache, falls back to the database and fills the cache. It is the safe default.
Write-through writes cache and database together: fresh reads, slower writes.
Write-back acknowledges from the cache and flushes later: fastest writes, risk of loss.
Pick the pattern from how fresh reads must be and how costly a lost write is.