Invalidation Races and Freshness Guarantees

01 The idea

The problem this lesson solves

You update the database and delete the cache key. A moment later the cache contains the old value again. No second writer changed the database. An earlier reader finished late and refilled stale data after your deletion. Cache invalidation is a concurrency problem: the order of reads, writes and fills matters as much as the command used to remove a key.

You should recognize the application, the database and the request path. Treat the database as the authority unless explicitly stated otherwise.

02 Worked example

Refill an old value after invalidation

03 The method

Understand the mechanism

Define the freshness promise per operation

Freshness describes how current a returned value must be relative to authoritative changes. A public content page may tolerate a short stale interval; an access revocation or ownership decision may not. Start with the user-visible contract rather than a default TTL.

Read-your-writes means a client can observe its own completed update on a later read under the stated session or operation scope. It is weaker than promising that every reader everywhere immediately observes the newest value. Monotonic reads prevent a client from going backward to an older observed version.

A cache can violate these expectations even when the database itself provides suitable guarantees. If the app reads an old local copy after a successful write, the user experiences stale behavior despite the authoritative row being correct.

Separate strict operations from tolerant ones where the product allows it. An owner’s confirmation path might read the authority, while anonymous browsing uses an explicitly bounded-staleness path. The distinction must be real in the implementation and documentation.

Walk the stale-fill race

Initially the database holds v1 and the cache is empty. Reader R misses and reads v1 from the database, then pauses before filling the cache. Writer W commits v2, deletes the cache key and reports success. R resumes and stores v1 with a fresh TTL.

The cache now contains old data after the writer’s invalidation. The delete command worked exactly as requested; it could not delete a fill that had not happened yet. “Delete after write” is therefore not by itself proof of immediate freshness.

If the writer instead deletes before committing, another reader can miss during the gap, read v1 and refill it before or after the commit. Changing the order alone does not eliminate every interleaving.

Draw the race with separate database and cache columns. This makes the authority and copy transitions visible. A single arrow labeled update cache hides the interval where the problem occurs.

Understand what TTL can and cannot bound

A TTL begins according to the cache insertion or refresh operation. If R read v1 long ago and fills it after W’s update, its new TTL starts late. The maximum age relative to the latest database change is not necessarily equal to the configured TTL.

To claim a bound, account for the age of the source read, maximum fill delay, expiry behavior and any upstream caches. An unbounded delayed fill destroys a simple “all readers fresh within thirty seconds of update” argument.

TTL remains useful: it limits residence of a particular entry and provides eventual refresh opportunities under ordinary operation. It is a repair mechanism for some stale-copy situations, not a substitute for a strict consistency protocol.

Be careful with stale-while-revalidate and stale-if-error policies. They intentionally permit serving older data under defined conditions. They can improve availability for suitable content, but they weaken freshness and must not be applied blindly to permissions or revoked destinations.

Compare invalidation, updates and versioned fills

Invalidation removes a copy and lets a later read refill it. Updating the cached value can reduce the next miss, but concurrent writers and delayed fills still need ordering. A slower writer or reader can overwrite a newer cache value unless the cache transition rejects older versions.

Versioned values can help if the compare-and-store is atomic and there is trustworthy version knowledge to compare against. Merely placing version=1 beside a value is insufficient when the cache is empty and accepts any incoming fill.

A design may maintain a version watermark, use generation-specific keys, or validate against an authoritative version before accepting a fill. Each adds state and ordering requirements. If validation and fill are separate and uncoordinated, another update can occur in between.

For a strict read path, bypassing the cache may be the clearest first choice, provided the authoritative read itself meets the required consistency. The performance cost is explicit and can be measured. Stronger cache coordination should be introduced only with a complete failure and race argument.

Keep multiple layers and messages in the model

A local app cache and a shared cache are two copies. Deleting the shared entry does not remove A’s local entry unless another mechanism connects them. Browser or CDN caching can retain an HTTP response independently of both.

Invalidation messages can arrive late, out of order, more than once or not at all under the transport and recovery model. Consumers need appropriate version/order handling and a way to recover after disconnection. A message bus labeled reliable does not eliminate the need to define these behaviors.

Reordering matters: an old update message must not replace a newer value. Duplicate invalidation is often harmless, while duplicate write application may not be. The event’s semantics determine what idempotency means.

Include tenant, representation and query identity in invalidation. Removing a7’s object key may not invalidate cached owner listings or derived search results that contain its old destination. Those projections need their own consistency contracts.

Test freshness with controlled interleavings

Ordinary sequential tests rarely expose late-fill races. Add a barrier in a practice loader after the authoritative read and before the cache write. Pause R at that barrier, perform W’s update and invalidation, then resume R. Inspect the cached value.

Repeat with multiple writers, delayed invalidation, local and shared caches, and a restarted invalidation consumer. Check the declared contract rather than assuming every stale observation is equally wrong. A permitted thirty-second-old public value differs from a stale authorization decision.

Observe value versions and fill timing where feasible without exposing sensitive content. A high hit ratio does not indicate freshness. Metrics need to reflect invalidation failures, rejected stale fills and divergence checks when those mechanisms are used.

The design is complete when it explains both the normal fast path and why an old operation cannot violate the promised read behavior. If the mechanism only reduces the probability of stale data, describe it as risk reduction rather than a guarantee.

R: cache miss → database returns v1 → pause
W: commit v2 → delete cache → acknowledge update
R: resume → cache.set(v1, ttl)
# Result: stale v1 exists after the delete.
# A stronger contract must reject this fill or avoid this read path.

database = {"a7": (1, "old")}
cache = {}
reader_value = database["a7"]  # R reads v1, then pauses.
database["a7"] = (2, "new")    # W commits v2.
cache.pop("a7", None)          # W invalidates.
cache["a7"] = reader_value     # R resumes its old fill.
print("database_version=", database["a7"][0], sep="")
print("cache_version=", cache["a7"][0], sep="")
print("stale=", cache["a7"][0] < database["a7"][0], sep="")

database_version=2
cache_version=1
stale=True

04 Cheat sheet

Review the decisions

Use this table to explain the mechanism and its limit without memorizing a product name.

05 Where & why

Check the primary references

Use official references for protocol and implementation details. The questions here are teaching prompts.

06 Interview questions

Explain the reasoning out loud

Answer before opening the explanation. The questions progress from vocabulary to decisions and failure behavior.

07 Practice problems

Practice a new case

Solve the new cases before revealing hints. Complete worked solutions follow the set.

Worked solutions