Synthesis: Canva's Revocation List and Coinbase's Freshness Tokens Are the Same Mechanism — an Async Correctness Signal Layered on Top of an Otherwise-Aggressive Cache
The connection
Two Architecture/CaseStudies notes added the same day (2026-08-09), about unrelated companies and unrelated data (session identity vs. user profile fields), independently solve "how do I cache aggressively for the 99% case while still being correct for the caller who just changed something" with the identical structural move:
- Canva: Stateless Session Cookies and Revocation at Hundreds of Millions of Users — the fast path is a fully stateless, encrypted cookie the gateway trusts without a lookup. Correctness for the "this needs to stop being valid right now" case comes from a separate, asynchronously-propagated revocation list: writes go to a database, an async worker uploads unpropagated revocations to S3, and every gateway holds the list in memory. The read path never pays for revocability; the write path (and a bounded propagation lag) pays for it instead.
- Coinbase: Fragment APIs and Federated Identity at 1.5M Reads/Second — the fast path is an aggressively cached read API. Correctness for the "I just wrote this, don't show me stale data" case comes from a Freshness Token returned on write: present it on a subsequent read and the service bypasses cache to guarantee at-least-as-fresh-as-that-version. The read path defaults to cheap and cached; the specific caller who needs a guarantee opts in via a token they already have.
Both notes independently name the same underlying insight in their own vocabulary — Canva's "stateless-by-default, revocation-list-as-the-exception... a more general pattern than session cookies," and Coinbase's "Freshness Tokens are the reusable idea here, independent of Coinbase or crypto" — but neither cites the other, and no existing vault note connects them as the same pattern applied to two different correctness questions (revoke vs. read-your-writes).
Why this matters
The two cases solve superficially different consistency problems — "make this stop being valid" (revocation) versus "make sure I see my own recent write" (read-your-writes) — which is exactly why the shared mechanism wasn't obvious on a single read of either note. But structurally both are answers to the identical design question: when a read path is optimized to avoid a lookup on every request, how do you handle the rare case where "the cached/stateless answer" is provably wrong for this specific caller, right now? Both land on the same three-part answer: (1) keep the hot path fully cache-friendly/stateless by default, (2) push the correctness-critical information onto a separate, cheap-to-check side channel (an in-memory revocation list; a caller-presented version token), and (3) accept and explicitly bound the cost of that side channel (propagation lag for Canva; an extra cache-bypass read for Coinbase) rather than paying it on every request.
This is a distinct pattern from Caching Strategies's general cache-aside/write-through tradeoffs — it's specifically about the exception path for an otherwise-aggressively-cached or stateless system, not the caching strategy itself. It's also distinct from Idempotency Keys (already the subject of this window's idempotency synthesis) even though both use a token/key returned to the caller — idempotency keys prevent a duplicate write; Freshness Tokens and revocation lists guarantee correctness on a subsequent read. The vault currently has no Fundamentals-level note naming this read-side pattern the way it has one for idempotency's write-side pattern.
What this suggests
- Both case studies' own "What to steal" sections already state the general form individually — worth a short cross-link between them (
canva-stateless-sessions-and-revocation.md's Related section pointing to Coinbase's Freshness Tokens, and vice versa) since each is the clearest existing "worked example" of the other's stated general principle. - This is a real candidate for a new
Architecture/Fundamentals/concept note — something like "Exception-Path Consistency" or "Correctness Tokens Over Cache Invalidation" — since the pattern now has two independent, well-documented real-world instances (the bar this vault's Fundamentals notes are typically held to) and currently has zero abstracted coverage; the closest existing note,caching-strategies.md, doesn't address the "how do you special-case just the caller who needs strong consistency" question at all. - Both instances share a subtler design detail worth flagging together: neither system tries to make revocation/freshness instant — both explicitly bound and accept a small amount of lag or extra cost rather than chasing full real-time consistency on the exception path, which mirrors the "propagation lag is a deliberate, bounded tradeoff, not an oversight" lesson already named in the Canva note alone. Worth generalizing that specific framing across both cases if the Fundamentals note gets written.