State lives in all three tiers, but authority does not. Valkey is authoritative for counters; PostgreSQL is authoritative for policy; L1 holds only a bounded, expiring claim on L2 and can be discarded at any moment without loss.
Local memory alone was rejected: N pods each enforcing the full quota multiplies it by N. A database alone was rejected: the p99 budget is 10 ms and a durable write is 10 to 200 ms.
The claim is what makes both properties available at once — L1 gives the latency, L2 gives the correctness, and the lease is the contract between them.
Numbers
L1 ≈ 0.3 ms p99, serving 92% of decisions. L2 ≈ 1.5 ms p99, serving 8%. L3 serves 0%.
Counter keys carry a TTL of two windows, so a shard that loses its data rebuilds correct state within 500 ms rather than needing a repair job.
Budget counters are refreshed from the ledger every 60 s — cost enforcement is deliberately eventually consistent, and view 09 explains why that is acceptable.
Risks
A cold pod has no lease and sends its first decision for each tenant to L2. During a large scale-out this raises L2 traffic sharply; leases are pre-warmed for the top 200 tenants at pod start.
Budget enforcement lagging by up to 60 s means a tenant can overspend by one minute of peak traffic. That is accepted and stated in the tenant contract; hard cost stops would need a synchronous ledger read on the hot path.
