What 'Invalidation' Actually Means

A cache holds a copy. The source of truth (database, upstream API, file system) holds the original. The moment the original changes, the copy is wrong. Invalidation is the act of removing or refreshing that copy so future reads see the new value.

There are only three things you can do when the source changes:

1. Delete the cached entry. Next read misses, repopulates from the source.
2. Overwrite the cached entry with the new value.
3. Wait for the TTL to expire and let the entry rot until then.

Every production caching system uses some combination of these three. The interesting design decisions are when to trigger which, and how to make the triggers reliable across failures and concurrent writers.

The Three Invalidation Modes

Mode 1: TTL-based (passive)

Every cached entry has an expiration. After it passes, the entry is treated as a miss. No coordination with the source is required.

Pros: zero coupling; cache and database know nothing about each other. Bounded staleness: data is at most TTL seconds old.

Cons: until the TTL expires, every reader sees the stale value. For a profile photo with TTL 5 minutes, the user sees their old picture for 5 minutes after upload - unacceptable.

When alone is fine: data that ages naturally and where stale-by-TTL is tolerable (top stories of the hour, weather, exchange rates with daily granularity).

Mode 2: Write-driven (active)

Whenever the source is updated, the application explicitly invalidates the cache key.

---------- Write-driven invalidation ----------
   client                                                   
     |                                                      
     v                                                      
  [ app server ] - 1. UPDATE ----> [ database ]            
                <- 2. ack          
  [ app server ] - 3. DEL key ---> [ cache ]               
                <- 4. ack                                   
     |                                                      
     v                                                      
   return success

Pros: cache becomes consistent within milliseconds of a write. Bounded staleness window is the time between steps 1 and 3.

Cons: requires every code path that writes to also invalidate. A new endpoint that forgets to invalidate silently serves stale data. The race conditions in step 1-3 are the source of most cache bugs (covered below).

Mode 3: Event-driven (reactive)

The application does not invalidate directly. Instead, the database emits change events (via change-data-capture or transactional outbox), and a worker consumes them and invalidates the cache.

---------- Event-driven invalidation ----------
  client - write --> [ app ] - write --> [ database ]
                                                |
                                                | (CDC stream: Debezium, MySQL binlog)
                                                v
                                          [ event bus (Kafka) ]
                                                |
                                                v
                                          [ invalidator worker ]
                                                |
                                                v
                                          [ cache ] DEL key

Pros: invalidation is decoupled from application code. Schema changes (new fields, new tables) automatically propagate. Works across language boundaries (a Java service writes; a Python worker invalidates a Redis cluster used by Go services).

Cons: more moving parts; CDC infrastructure (Debezium, Maxwell) must be operated. Higher latency between write and invalidation (typically 100 ms to 1 s).

When alone is fine: large microservice architectures where many services share a cache and you cannot trust every team to invalidate manually.

The Canonical Race: Update-Then-Invalidate

The most common cache pattern is 'cache-aside read, update database then delete cache'. There are exactly four orderings for this code path under concurrent writes, and one of them silently produces stale data forever.

Consider two clients writing different values for the same key, with two operations each (DB write, cache delete):

---------- Lost-update race ----------
T0  Client A: UPDATE users SET name='Alice'   --> DB
T1  Client B: UPDATE users SET name='Bob'     --> DB     (DB now has 'Bob')
T2  Client B: DEL user:42                     --> cache  (cache now empty)
T3  Reader R: GET user:42 --> miss            -> SELECT --> 'Bob' --> SET cache='Bob'  (cache has 'Bob', correct)
T4  Client A: DEL user:42                     --> cache  (cache empty again)
T5  Reader R: GET user:42 --> miss            -> SELECT --> 'Bob' --> SET cache='Bob'  (still correct)

The DEL-after-UPDATE pattern is safe because deletes are idempotent. The next reader fetches from the source.

Now consider the broken pattern - 'update database, then SET cache':

---------- The bug: update-then-SET ----------
T0  Client A: UPDATE users SET name='Alice'   --> DB
T1  Client B: UPDATE users SET name='Bob'     --> DB     (DB now has 'Bob')
T2  Client B: SET user:42 = 'Bob'             --> cache  (cache is 'Bob', correct)
T3  Client A: SET user:42 = 'Alice'           --> cache  (cache is 'Alice', WRONG!)

The cache now permanently disagrees with the database. Until the TTL expires (or someone manually deletes the key), every reader sees 'Alice' even though the source says 'Bob'.

The rule: on a write, always DELETE the cache, never SET it. Let the next reader repopulate.

A second race: read populates an old value

Even with DELETE on write, there is a subtler race:

---------- Read-populates-stale race ----------
T0  Reader R:  GET user:42 --> miss
T1  Reader R:  SELECT user where id=42 --> 'old' (from leader or replica)
T2  Client W:  UPDATE users SET name='new' --> DB
T3  Client W:  DEL user:42 --> cache (was already empty)
T4  Reader R:  SET user:42 = 'old'         --> cache now holds STALE 'old'

The writer's invalidation came between the reader's miss and the reader's populate. The cache is now stale until the next write or TTL.

Mitigations:

1. Short TTL on populated entries so the staleness is bounded (typically 5 to 60 seconds for sensitive data).
2. Versioned reads: the reader includes a 'last-seen DB version' (LSN, oplog timestamp) and only writes the cache if the version is fresh. Compare-and-set in Redis (WATCH/MULTI/EXEC).
3. Read-your-writes routing: writers tag their session and read from the database for a short window after a write to verify the invalidation took.

DELETE vs SET vs Versioned Keys

Three primitives, three trade-offs.

The versioned-key pattern is what GitHub uses for repository pages, what Wikipedia uses for article rendering, and what the AWS console uses for resource lists. It is the safest choice when you cannot afford even brief stale reads.

The Dual-Write Problem

A write must touch two systems: the database (source of truth) and the cache (or the event bus). What happens if the second write fails?

---------- Dual-write failure ----------
  app - UPDATE DB --> ok
  app - DEL cache --> network timeout
  ?? cache now permanently stale, no retry, no error to caller

Naive code retries inline, but a process crash between the two calls leaves the cache stale forever.

Solution 1: Transactional Outbox

Write the database change and the invalidation event in the same transaction by writing the event to an outbox table in the same database. A separate poller reads the outbox and emits invalidation events to the cache (or to a queue). If the application crashes, the next poll cycle picks up the unsent event.

BEGIN;
UPDATE users SET name = 'Alice' WHERE id = 42;
INSERT INTO outbox (event_type, key, created_at)
    VALUES ('invalidate', 'user:42', NOW());
COMMIT;

A worker tails the outbox table (SELECT ... ORDER BY id WHERE sent = false LIMIT 100), publishes each event, and marks it sent. At-least-once delivery; consumers (cache invalidator) must be idempotent (which DEL already is).

Solution 2: Change Data Capture (CDC)

Let the database itself be the event source. Tools like Debezium tail the binary log (MySQL binlog, Postgres WAL, MongoDB oplog) and publish row-level change events to Kafka. The cache invalidator consumes these and deletes affected keys.

No application code changes needed; every UPDATE/INSERT/DELETE is captured automatically. The cost is operating Debezium and a Kafka cluster, but for organizations that already run them, CDC is the cleanest answer to the dual-write problem.

Consistency Models a Cache Can Offer

State the model, do not hope your interviewer infers it.

Most caches sit at 'eventually consistent within ~100 ms of a write' or 'bounded staleness of 30 seconds via TTL'. Both are acceptable; the failure mode is when the team thinks they have strong consistency and they actually don't.

Implementing read-your-writes with a session marker

// On write, stamp the session with a timestamp.
async function updateProfile(userId, patch, session) {
    await db.update('users', userId, patch);
    await cache.del(`user:${userId}`);
    session.lastWriteAt = Date.now();
}

// On read, if recent write, bypass the cache.
async function getProfile(userId, session) {
    const recentWrite = session.lastWriteAt && Date.now() - session.lastWriteAt < 5000;
    if (recentWrite) {
        return await db.findOne('users', userId);
    }
    return await cacheAsideGet(`user:${userId}`, () => db.findOne('users', userId));
}

Cross-Region Invalidation

With caches in multiple regions, an invalidation must reach every region. Two approaches.

Pub/sub bus

Every region subscribes to a global topic. On write, the writer publishes an invalidation event. Each region's subscriber processes it and deletes the local cache key.

Pros: simple; works with any cache. Latency: 100 to 500 ms cross-region. Cons: pub/sub bus is a single point of failure; partition between regions delays invalidation; need a dead-letter queue for missed messages.

Per-region CDC + replication of the bus

Each region runs its own CDC pipeline tailing the local replica of the database. The pipeline publishes invalidation events to a regional Kafka cluster. A cache invalidator in each region consumes only its own region's events.

Pros: no cross-region coupling on the hot path. Survives region partitions; each region invalidates from its local CDC stream once the database replica catches up. Cons: requires database replication (which you usually have anyway) and per-region CDC infrastructure.

At scale, the second pattern wins. It is what Stripe, Uber, and Airbnb use for their cross-region cache layers.