CONCEPT Cited by 1 source
Revocation feed subscription¶
A revocation feed subscription is a cache-invalidation strategy for token systems: instead of replicating a global blacklist to every verifier, the authority exports a feed of revocation notifications that verifier clients subscribe to (in practice, poll) and use to prune their local verification caches.
Fly.io's framing:
"The obvious challenge here is caching; over 98% of our validation requests never hit
tkdb. We certainly don't want to propagate the blacklist database to 35 regions around the globe. Instead, thetkdb'verification' API exports an endpoint that provides a feed of revocation notifications. Our client library 'subscribes' to this API (really, it just polls). Macaroons are revoked regularly (but not constantly), and when that happens, clients notice and prune their caches." (Source: sources/2025-03-27-flyio-operationalizing-macaroons.)
Why it's the right shape¶
- Revocations are rare. Feeding deltas is cheap; mirroring the whole blacklist is expensive.
- Cache-pruning is an idempotent application of the feed. Clients don't need to solve ordering or replication; they apply revocations in arrival order.
- The authority remains the source of truth. The feed is a notification optimization, not a second database.
Fail-closed on disconnect¶
Critical property — if clients lose connectivity to the
authority past a threshold, they "dump their entire cache,
forcing verification to happen at tkdb". No stale-positive
verifications possible.
Contrast: replicated blacklist¶
The naïve alternative — ship the blacklist database globally — scales badly (blacklist size × verifier count) and creates stale-read failure modes. Feed-based invalidation scales with revocation rate rather than token-population size.
Seen in¶
- sources/2025-03-27-flyio-operationalizing-macaroons — canonical wiki instance; >98% cache hit rate with feed-based pruning and fail-closed disconnect handling.