Watch & compare
Cache-aside
Different ways to see the same idea. Play one cut at a time, then return to the guide to try it yourself.
Why we recommend A hit can be stale
Start with Astra: the source changes to v2 while the cache and agent still hold v1, making the cost of a stale tool result visible before showing explicit recovery. Baseline is the simpler introduction to misses, hits and expiry; Fable is the stronger follow-on for reproducing a delayed refill that defeats deletion. Astra offers the clearest first viewing at phone size, while Fable’s overlapping reader and writer reward a pause or replay.
Revised original · 24 sec
Miss, hit and expiry
The application owns lookup, database read and cache fill. A hit avoids a source read, while expiration causes a later miss.
Read the video sequence
- 0–8s: The caller asks the application for data. A cache miss causes a database read, cache fill and response. The TTL bar begins draining immediately when the entry is stored.
- 8.5–15.5s: A later request hits without a database read or TTL renewal. The bar keeps draining, the clock marks the approaching expiry, and the entry expires at 14.5s.
- 16–24s: A new request misses and repeats the source read and cache fill. The caller receives the result before the stage fades; the title remains at both loop boundaries.
About this cut
Production: Original prototype; model not recorded.
Revision: gpt-6-astra comparative review.
Illustrative timing; no performance benchmark or recommended TTL.
No source writes or concurrency are shown; a hit or unexpired entry does not prove freshness.
Audio analysed, not listened to.
Recommended · Astra · 31 sec
A hit can be stale
Recognize a stale runbook cache hit and trace explicit invalidation followed by a tool-managed source read and refill.
Read the video sequence
- The agent asks a read tool for a runbook. The tool finds revision 1 in the cache and returns it without reading the source. Both stored copies currently match.
- An independent edit commits revision 2 to the source. The next request still gets revision 1 from the cache. Red highlighting reveals the mismatch to the viewer; it does not represent automatic freshness detection.
- An explicit recovery action deletes the cached guide after the source edit. The cache entry becomes empty. The agent still holds its previously returned revision 1.
- The next lookup misses. The tool reads revision 2 from the source, writes it into the cache, and returns it to the agent. This example assumes those operations succeed without concurrent writes.
- A repeat request now uses cached revision 2. The matching revisions hold on screen before a fade to black. This demonstrates reuse after recovery, not a guarantee that future reads remain fresh.
About this cut
Production: gpt-6-astra.
Illustrative serialized recovery; invalidation does not guarantee consistency under concurrent writes, stale fills or failed deletion.
Red highlighting shows the viewer a revision mismatch; the tool does not automatically detect stale data.
The editor and invalidation trigger are abstracted; the application layer owns deletion and refill.
TTL, permissions, outages and deployment execution are outside this cut; prompts do not enforce permissions.
Sound analyzed, not physically listened to; self-reviewed without a comparative recommendation.
Alternative · Fable · 32 sec
Invalidation can lose a race
A reader can refill an old policy after a newer source commit and cache deletion. In this example the stale entry remains until its TTL expires, measured from the late fill; expiration does not guarantee fresh source data.
Read the video sequence
- 0.7–2.6s: The Agent asks for the refund policy. The cache holds 30d, answers HIT, and the Agent receives 30d while the database stays untouched.
- 4.2–5.6s: The Editor saves 14d. The app updates the database to 14d and deletes the cached refund entry while its TTL bar still had time left.
- 6.7–13.6s: The Agent's next read misses, reads 14d from the database, and the app holds the pending SET 14d. During that pause the Editor saves 7d: the database becomes 7d and the delete finds an empty cache. The held SET 14d then lands with a crash, storing the old value in red; the Agent receives 14d.
- 15.0–20.5s: Two later reads hit the stale entry. The Agent's badge reads STALE 14d while the database shows 7d in green. The STALE label is the video's annotation, not something a cache reports.
- 21.3–22.9s: A clock spins with accelerating ticks as the entry's TTL bar runs out; the stale entry disappears.
- 23.6–31.6s: The next read misses, reads 7d, stores it in green, and the Agent receives 7d with a chime. The resolved state holds, then the diagram fades to black while the title and subtitle remain, matching the opening frame.
About this cut
Production: anthropic/claude-fable-5-1.
Revision: gpt-6-astra comparative review.
Illustrative scenario: the pause between reading the database and setting the cache stands in for any reordering (pauses, retries, slow networks); no claim is made about how often it happens.
The TTL bounds this entry’s remaining cache residence from its late fill, not data age since the source changed. No hit renews it and no further stale fill occurs here; expiry is not a general freshness guarantee. The lease-token mechanism in Nishtala et al. §3.2.1 prevents stale sets; it is not shown.
The Agent, Editor and refund-policy values are an example; the mechanism applies to any cache-aside reader and writer. The STALE badge is an annotation, not a cache feature.
One key and one cache node; replicated caches and multi-node invalidation are out of scope.
Audio was checked by decoded peak level (-1.8 dBFS), per-cue onset energy and spectrogram, not listened to.
30d, 14d and 7d are example refund-policy values, not cache lifetimes. The draining bar represents the separate TTL.
These animations use sound effects rather than narration. The written guide explains the mechanism and its limits. Model names describe how a cut was made, not a quality ranking.
What the review found
- Baseline 00:00.6–00:06.6 and 00:08.6–00:11.5 makes application-owned fetch/fill and database avoidance easiest to trace. Its revised TTL bar drains from insertion through the hit to expiry at 00:14.5, but no source write occurs, so this cut alone cannot teach freshness.
- Astra 00:06.4–00:11.8 leaves v1 visible in the cache and agent after the source becomes v2. Its large version fields and HIT ≠ FRESH conclusion communicate the chapter’s central warning more directly than Baseline’s envelopes or Fable’s smaller policy rows.
- Astra 00:14.1–00:23.35 shows explicit deletion, a subsequent miss, source read, cache fill and delivery in that order. The agent retains its old result until the new response arrives; deletion does not repair already-returned data. The editor and recovery trigger are abstracted, and this serialized success is not a concurrency guarantee.
- Fable 00:10.2–00:13.6 holds SET 14d while a writer commits 7d and deletes the empty key, then lets the old fill land. This concrete race is absent from the other cuts and directly supports the guide’s paused-reader exercise. Enlarged values and feedback beside the row fix the original phone-legibility and value-overlap weaknesses.
- Fable 00:15–00:22.94 shows two stale hits without renewing the entry’s TTL, then expiration. This reinforces persistence but makes the 31.57-second cut denser than Astra; 30d/14d/7d are policy values, and the clock limits this cache entry after its late insertion, not the age of source data.
- Baseline delivers its final response at 00:22, Astra at 00:28.25, and Fable at 00:27.67. All leave a readable outcome before fading and have pixel-identical first/last decoded frames; Baseline and Fable retain their titles, while Astra returns to an empty dark frame.