CONCEPT Cited by 1 source
Verification cache¶
A verification cache is a local (client-side or edge) cache of token-verification results, letting a verifier skip the round-trip to the token authority for tokens it has already seen.
Fly.io's canonical datum:
"Macaroons, as it turns out, cache beautifully. ... Our client libraries cache verifications, and the cache ratio for verification is over 98%." (Source: sources/2025-03-27-flyio-operationalizing-macaroons.)
Why Macaroons cache well¶
The chained-HMAC construction gives verification an inheritance property: if you've verified a parent Macaroon, any more-specific (attenuated) descendant is verifiable locally — replay the additional caveats' HMACs from the known-good parent tag. No authority contact needed for descendants.
This is architecturally unusual: a cache hit on parent-X is also a cache hit for any descendant of X a caller presents.
The revocation problem (solved)¶
A naïve verification cache is an anti-pattern: revoked tokens can stay "valid" in caches forever. Fly.io's answer is the revocation feed subscription — clients subscribe to revocation notifications and prune on arrival; on connectivity loss past threshold, the entire cache is dumped.
Performance impact¶
At 98%+ hit rate, "transoceanic links" on the auth path are avoided in steady state — the authority serves only the 2% cold misses plus the revocation-feed subscription traffic. For an online-stateful token system at global scale, this is the difference between usable and unusable.
Seen in¶
- sources/2025-03-27-flyio-operationalizing-macaroons — canonical wiki instance; 98%+ verification cache hit rate explicitly stated as load-bearing.