The question

Every read has the same shape: the data might be in the cache, or it might not. What happens on a miss?

There are three answers, and the difference between the first two is who is responsible.

Cache-aside

Cache-aside — also called lazy loading — means your application manages the cache directly. It is the most common pattern in use, and the default you should assume unless there is a reason otherwise.

value = cache.get(key)

if value is not None:
    return value                 # HIT

value = database.query(key)      # MISS — application fetches
cache.set(key, value, ttl=300)   # application stores
return value

The application talks to both the cache and the database, and it owns every step.

Why people use it:

• Only requested data is cached. Nothing is stored that nobody wants.
• If the cache is unavailable, the app can fall back to the database, as long as the database can handle the extra load.
• It works with any cache and any database. No special library required.
• You can see exactly what is happening.

The costs:

• Every miss pays three trips: check cache, query database, write cache.
• The logic is repeated everywhere you cache something, and someone will eventually get it wrong.
• It has a specific race condition, which is the second half of this lesson.

Read-through

Read-through means your application only ever talks to the cache. The cache knows how to load missing data by itself.

value = cache.get(key)    # cache handles the miss internally
return value

You configure the cache with a loader function — the code that fetches from the database — and the cache calls it when it needs to.

The distinction is exactly this:

That is the whole difference. Not performance, not freshness — responsibility. And because it decides where the logic lives, it decides where the bugs live.

Why people use it: the loading logic exists once, not scattered everywhere. Application code becomes simple. Many caching libraries do the hard parts (like the race below) for you.

The costs: you need a library that supports it. The cache going down is now harder to survive, because your app has no other path to the data. And the loading logic is one step further from the code that uses it.

Refresh-ahead

Both patterns above are reactive: a user hits a miss, and that user waits while the data loads.

Refresh-ahead is proactive. For values you know are hot, refresh them before they expire, so no user ever encounters the miss.

TTL = 300 seconds, refresh at 240

t=0    value cached
t=240  ─→ background job refreshes it   (no user is waiting)
t=245  value replaced, timer resets
       ...no user ever sees a miss on this key

Why people use it: for hot keys, misses effectively disappear. Your p99 latency — the slow tail you will meet in Lesson 13 — improves dramatically, because the tail was the misses.

The costs: you refresh values that may never be requested again, so you do work for nothing. You need to identify which keys deserve it. Applying it to everything is a way to generate constant pointless load.

Which realm uses which

Notice the pattern: when you own the code, you get cache-aside. When someone else built the cache, you get read-through. The techniques are the same everywhere; only the ownership moves.

The race: many readers, one missing key

Here is the flaw in cache-aside, and it is not a rare edge case — it is a guaranteed event on any popular key.

The front-page product is requested 1,000 times per second. Its cached value expires.

t=0.000   TTL expires
t=0.001   Request 1    → miss → queries database
t=0.001   Request 2    → miss → queries database
t=0.001   Request 3    → miss → queries database
   ...
t=0.001   Request 1000 → miss → queries database
t=0.050   first query returns, cache is written
          — 49 milliseconds too late for the other 999

The cache did not fail. Every one of those requests followed cache-aside correctly. The pattern has a gap between “the value expired” and “the value has been reloaded,” and every request arriving in that gap goes to the database.

Worse, this is self-amplifying. A thousand simultaneous queries slow the database, which makes the reload take longer, which widens the gap, which lets more requests through.

Single-flight

Request coalescing — usually called single-flight — fixes it: when many requests need the same missing key, one of them fetches it, and the rest wait for that one result.

t=0.001   Request 1    → miss → acquires the loader slot → queries database
t=0.001   Request 2    → miss → someone is loading → waits
t=0.001   Request 3    → miss → someone is loading → waits
   ...
t=0.050   Request 1 gets the value, stores it, and hands it to all 999 waiters

One database query. All 1,000 requests served.

The shape:

def get(key):
    value = cache.get(key)
    if value is not None:
        return value

    # only one caller per key gets past this point;
    # the others block here and receive the same result
    with single_flight(key):
        value = cache.get(key)        # check again — someone may have
        if value is not None:         # filled it while we waited
            return value
        value = database.query(key)
        cache.set(key, value, ttl=300)
        return value

Two details that matter:

• The second cache.get is not redundant. By the time a waiter is released, the value usually exists. Checking again avoids a pointless second query. This is the double-checked pattern.
• The lock is per key, not global. A global lock would make every miss on every key wait behind every other, which would be far worse than the problem.

Most mature caching libraries provide this. It is worth knowing it exists before you need it — and you are about to need it.

At the Storefront

Cache-aside for product details, with single-flight — it is the front page item and it will stampede.

Refresh-ahead for the category tree — small, hot, expensive, on every page.

Nothing for the cart badge, in any pattern.

The problem

Reading was straightforward: the value is there or it is not.

Writing is harder, because now two places hold the same fact — the cache and the database — and a write must deal with both. Between the moment you update one and the moment you update the other, they disagree.

There are three strategies. They differ in when the database is written and whether the cache is written at all.

Write-through

Write-through means the cache owns the write. Your application writes to the cache, the cache writes to the database, and the call does not return until the database write has completed.

Both writes happen — but one after the other, not at the same time. The caller waits for the whole chain.

Application → cache.put(key, value)
                    ↓
              cache writes to the database
                    ↓
              database confirms
                    ↓
Application ← success

Note who is doing the work: the cache talks to the database, not your application. That is what makes it through — and it is the same distinction that separates read-through from cache-aside.

Implementations differ on the order. Some write the cache first, then the database. Oracle's Coherence writes the database first and updates the cache only once that has succeeded, so that a failed database write can never leave a value sitting in the cache that the database has never seen.

Why people use it: the cache is never behind the database, because success is not reported until the database has the write. A subsequent read is correct. Reasoning about the system is simple.

The costs:

• Writes are slower. You pay for both systems on every write.
• You cache things nobody reads. Every write populates the cache, whether or not that item will ever be requested. On write-heavy data with few reads, you fill your cache with dead weight and evict things people actually want.
• It is not actually atomic. Writing to two systems without a transaction spanning both means one can succeed and the other fail. If the cache write succeeds and the database write fails, your cache now holds a value that does not exist in the source of truth — which is worse than being stale.

Where you would use it

• Account and profile settings. Someone changes their display name and lands straight back on a page showing it. The cache is already correct when that page renders.
• Feature flags and configuration. Written rarely, read on nearly every request, and every server needs the new value at once.
• Stock counts on a low-volume catalogue. Being wrong means overselling, and the write rate is low enough that the extra latency does not matter.
• Shopping cart contents. Written, then immediately read on the next page, every time.

Write-behind

Write-behind — also called write-back — writes to the cache, returns success immediately, and writes to the database later in the background.

Application → write to cache → return success   ← user is done here
                             ↓
                    (later) write to database

Why people use it:

• Writes are very fast. The user waits for a memory write, not a disk write.
• Writes can be batched. A counter updated 1,000 times in a second becomes one database write of the final value. For write-heavy workloads this is a genuine order-of-magnitude reduction in database load.
• Sudden write spikes get absorbed instead of overwhelming the database.

The cost, stated plainly: you can lose data.

If the cache dies between the acknowledgement and the database write, that write is gone. You told the user it succeeded. It did not.

This is not a rare edge case to design around — it is the fundamental trade. Write-behind is correct for data where losing some is acceptable. It is wrong for orders, payments, and inventory.

Where you would use it

• View counts. A page viewed a million times an hour becomes a handful of database writes instead of a million.
• “Last seen” and “last active” timestamps. Updated on every single request, and nobody notices if one is a minute stale or lost entirely.
• Likes, reactions, and vote tallies. High volume, and an occasional lost increment is invisible.
• Analytics and telemetry events. Losing a fraction of a percent does not change any dashboard anyone looks at.

Write-around

Write-around writes only to the database and does not populate the cache at all. Usually it also removes any existing cached copy, so a stale one cannot survive.

Application → write to database → return success
              (cache entry deleted if present)
              next read misses and loads fresh

Why people use it: write-heavy data that is rarely read soon after writing does not pollute the cache. Your cache stays full of things people are actually reading.

The cost: the next read of that item is a miss. If your write pattern is “write then immediately read” — which is extremely common, since users usually look at what they just did — write-around gives you a guaranteed miss on every one.

Where you would use it

• Bulk imports and migrations. Loading a million rows overnight. Filling the cache with all of them would evict everything real users actually want — the exact scan problem you will meet in Lesson 10.
• Audit logs and event records. Written constantly, read almost never, and usually only during an investigation.
• Historical and archival data. An order from three years ago is written once and may never be read again.
• Draft autosave. A user saves every few seconds; only the final version is ever read by anybody else.
• Sensor and IoT readings. High write volume, queried later in aggregate rather than individually.

Choosing

That last row deserves attention. Write-around paired with cache-aside — write to the database, delete the cached copy, let the next read reload it — is the most widely used combination in practice, because it is simple and it fails safely. It is also, under a different name, the subject of Lesson 11.

At the Storefront

Stock count — decrements constantly, and being wrong means selling something you do not have. Write-through keeps the cache from showing more stock than exists, but note that a write strategy alone does not make a decrement safe: two servers can both read 5, both subtract 1, and both write 4. That is the read-modify-write race from Lesson 6, and it needs an atomic decrement rather than a write pattern. Not caching the stock count at all is a legitimate answer here.

Review submission — written rarely, read constantly. Write-around: store it, drop the cached review list, let the next reader rebuild it.

Product view counter — written on every page view, read almost never, and losing a few is fine. Write-behind, batched.

Three write paths, three different strategies, on one page.

Two different reasons data leaves

Things disappear from a cache for two reasons, and the two have nothing to do with each other.

1. Expiration — the copy got old, so you stopped trusting it.
2. Eviction — you ran out of room, so something had to go.

That is the whole distinction. It is worth stating that plainly, because the two are confused constantly — including in documentation.

Expiration is time-driven. It is about correctness. The value may still be perfectly useful and there may be plenty of memory — you remove it because you no longer believe it.

Eviction is memory-driven. It is about capacity. The value might be perfectly current and useful — you remove it because something else needs the space.

A cache with infinite memory still needs expiration. A cache holding data that never changes still needs eviction. They are independent, and confusing them leads to setting TTLs to manage memory (which makes your data needlessly stale) or sizing memory to manage freshness (which does not work at all).

TTL, used deliberately

You met TTL in Lesson 2. Now use it for two distinct jobs.

TTL as a correctness tool. The TTL is your statement about how wrong you are willing to be. TTL = 300 says: I accept this may be up to five minutes out of date. Pick it from the business requirement, not from habit.

TTL as a safety net. This one is subtle and important. Even with perfect invalidation (Lesson 11), things go wrong — a message is dropped, a service is down, a code path is missed. TTL bounds the damage. Without it, a failed invalidation means a value is wrong forever. With it, the worst case is bounded by the TTL.

TTL jitter

Set 10,000 keys during a deployment, all with TTL = 3600.

One hour later, all 10,000 expire in the same second.

Jitter is adding a small random amount to each TTL so they spread out:

ttl = 3600 + random(0, 600)     # between 60 and 70 minutes

Now those 10,000 keys expire spread across ten minutes rather than in a single instant. This single line prevents a specific attack in Lesson 12, and it costs you nothing.

Eviction policies

When the cache is full and something new arrives, something old must go. The eviction policy decides what.

Choosing

Real caches offer combinations — Redis has allkeys-lru, volatile-lru (only keys with a TTL set), allkeys-lfu, volatile-ttl (shortest remaining life first), and noeviction (reject writes when full).

volatile-* variants matter more than they look: they let you mark some entries as never-evictable by giving them no TTL, protecting data you cannot afford to lose.

Reading the eviction rate

The eviction rate — how many items are being removed per second for lack of space — is one of the most useful signals a cache gives you.

• Near zero: your cache is big enough. Good.
• High and rising: your cache is too small. Items are being thrown out before they can be reused, and your hit ratio is being destroyed by capacity, not by TTL.
• Sudden spike: something just flooded the cache. A batch job, a scan, a bug writing far too much.

A high eviction rate paired with a falling hit ratio is a specific, actionable diagnosis: the cache needs more memory, or you are caching too much. Lesson 13 will show you where to watch this.

At the Storefront

Policy for the Redis instance: allkeys-lru as the default — and check for batch jobs that scan products, because those will wreck it. If you have one, either route it around the cache or move to windowed LFU.

The hardest problem in the course

The moment you cache something, the same fact exists in two places:

• The original, in your database. This is the truth.
• The copy, in your cache. This is what your users actually see.

Two places holding one fact can disagree — and when they do, the cache has no idea. Nothing tells it the database moved on without it.

Staleness is a cached copy no longer matching the truth it was copied from. It is not an error state — a stale cache does not crash, log a warning, or fail a health check. It quietly serves a wrong answer with complete confidence.

Three questions

Before choosing a technique, answer these for the data in question:

1. How wrong can it be? A view count off by three is fine. A price off by £5 is a legal problem.

2. For how long? Seconds, minutes, hours?

3. What does being wrong cost? A stale description is an annoyance. A stale stock count is an oversold order, a refund, and an angry customer.

These answers give you your TTL and tell you how much effort invalidation deserves. Data that can be five minutes stale needs a TTL and nothing else. Data that must be correct within a second needs real machinery.

Invalidate-on-write

The standard approach, and the natural partner to cache-aside from Lesson 8:

On write:
    database.update(key, new_value)
    cache.delete(key)

On the next read:
    cache miss → load from database → cache the fresh value

Update the truth, remove the copy, let it rebuild on demand.

Delete — do not update in place. Writing the new value into the cache looks better, because it saves the next reader a miss. It is not. Two administrators change a price at nearly the same time:

t=0   Writer A: database ← 10
t=1   Writer B: database ← 12
      Database is now 12.  ✓ correct

t=2   Writer B: cache ← 12
t=3   Writer A: cache ← 10        ← arrived late
      Cache is now 10.  ✗ WRONG

Both writes reached the database in order. The two cache writes did not — network timing, thread scheduling, a garbage-collection pause. The cache now serves 10 until its TTL runs out.

A delete cannot go wrong that way, because it carries no value. Whatever order two deletes land in, the result is the same: no cached copy, and the next read takes the truth from the source.

This is write-around from Lesson 9, seen from the invalidation side. Write-through is exempt: there the cache owns the write path, so it decides the order both systems see.

Versioned keys

A different approach: never delete anything. Change the name instead.

When a price changes you leave the cached copy exactly where it is — and start reading from a different key. The version lives in a small key of its own:

product:42:version  =  7

Reading a price becomes two steps:

1. read  product:42:version     →  7
2. read  product:42:price:v7    →  £25.00

When the price changes, the writer updates the database and increments the version:

product:42:version  =  8

The next reader takes the same two steps and lands somewhere else:

1. read  product:42:version     →  8
2. read  product:42:price:v8    →  miss → loads £20.00 from the database

Nothing was deleted. product:42:price:v7 is still sitting in the cache holding £25.00 — but nobody will ever ask for it again, and it expires on its own.

“Haven't you just added a lookup?” Yes — one, on a tiny key that is read constantly and is therefore always hot. In exchange you never issue a delete, and one version can retire any number of keys at once.

Often you do not need a counter at all. Anything that already changes when the data changes will do:

product:42:price:v<updated_at>
product:42:price:v<row_version>

Now the version is a fact the row already carries, and there is nothing extra to maintain. This is the common case for caching anything derived from a row you have already loaded — a rendered HTML fragment, a computed shipping estimate, a formatted price.

Browser        GET /product/42                    ← no version anywhere
                    ↓
Controller     ProductController.Get(42)          ← no version here either
                    ↓
Service        GetPriceAsync(42)
                    │
                    │  1. read  product:42:version      → 7
                    │  2. build product:42:price:v7
                    │  3. read that key                 → £25.00  (hit)
                    ↓
Response       £25.00

public async Task<decimal> GetPriceAsync(int id)
{
    // 1. the version pointer — a tiny key, read constantly, always hot
    var version = await _cache.StringGetAsync($"product:{id}:version") ?? 1;

    // 2. build the real key from it
    var key = $"product:{id}:price:v{version}";

    // 3. ordinary cache-aside from here on
    var cached = await _cache.StringGetAsync(key);
    if (cached.HasValue) return (decimal)cached;

    var price = await _repo.GetPriceAsync(id);
    await _cache.StringSetAsync(key, price, TimeSpan.FromMinutes(30));
    return price;
}

public async Task UpdatePriceAsync(int id, decimal price)
{
    await _repo.UpdatePriceAsync(id, price);                    // database first
    await _cache.StringIncrementAsync($"product:{id}:version"); // 7 → 8
}

Retiring many keys at once

Put the version in a prefix rather than a suffix and it covers everything beneath it:

catalog:v3:product:42
catalog:v3:product:99
catalog:v3:category:8

Increment that single version to v4 and every catalog key becomes unreachable in one operation. No message has to reach every cache node, and no key has to be found and deleted.

Why this is powerful:

• No invalidation race. Nothing is being deleted, so nothing can be deleted at the wrong moment.
• No purge cost. No message needs to reach every cache node.
• It works in realms you cannot reach. You cannot delete anything from a user's browser cache — but you can serve a page referencing a new name, and the old entry becomes irrelevant. This is the only mechanism that works for the browser realm.

The costs: you must track the current version and get it to everyone who builds keys. Old entries occupy memory until they expire, so you are paying for garbage for a while.

You have now seen this three times: fingerprinted filenames in Lesson 3, versioned URLs in Lesson 4, versioned keys here. It is the same technique, and it is the strongest tool in this lesson.

Same idea, but do not conflate them — they act at different layers and reach different people.

The practical consequence: bumping an internal version fixes every copy on your servers instantly, and does nothing whatsoever for the copy already sitting on a reader's disk. If a corrected price has to reach a browser sooner, that is a lifetime decision — the max-age you chose in Lesson 3 — not a versioning one.

Fingerprinting changes what the reader asks for. Versioned keys change what you look under. Only the first one can reach a copy you have already given away.

Invalidating across all four realms

Here is where the whole course converges. A price changes. Where does the old value live?

Read the first row again, because it governs your whole design:

This is the reason the storefront's price header in Lesson 3 was max-age=60 and not max-age=3600. Your browser TTL is not a performance setting — it is a hard limit on how fast a correction can possibly reach your users. Set it to the longest wrong-answer window you can defend.

And it is the reason versioned URLs matter so much: they are the only way to make a change reach a browser instantly, because they do not require reaching the browser at all.

The repopulation race

One more trap, and it defeats people who have done everything else correctly.

t=0   Reader:  cache miss → begins reading database → gets 10
t=1   Writer:  database ← 12
t=2   Writer:  cache.delete("price")        ← correctly invalidated
t=3   Reader:  cache.set("price", 10)       ← writes the stale value it
                                              fetched at t=0

The cache now holds 10, was correctly invalidated, and will serve the wrong value until its TTL expires. Every step followed the rules. The reader was simply holding a stale value in flight when the delete happened.

The reader's two steps — read the database, then write the cache — have to be atomic with respect to writers. Each step is already atomic on its own; the gap between them is the problem. Close it by holding a lock across both, or by making the cache write conditional so it fails if the key changed underneath it.

Versioned keys sidestep it entirely. The in-flight reader writes to v7 while everyone has moved on to v8, so its stale value lands where nobody is looking. And where neither is in place, a TTL still bounds how long the damage lasts.

TTL as the safety net

Every technique in this lesson can fail. Messages get dropped. Services restart mid-broadcast. Somebody adds a write path and forgets the invalidation. The repopulation race happens.

TTL is what stops any of those becoming permanent.

That sentence is the practical summary of this lesson.

At the Storefront

Trace a price change from £25 to £20:

Admin saves £20
    ↓
Database updated                              ← truth, immediately
    ↓
Redis: DELETE price:42:GBP:retail             ← immediate
    ↓
CDN: purge /product/42                        ← seconds
    ↓
Browsers: no direct mechanism                  ← up to 10s, by your own TTL

The browser may reuse a price response for up to 10 seconds. Monitor CDN purges and invalidation delivery too, because their timing determines when the other copies change.

That single trace is what Lesson 14 asks you to produce for every mutable element.