Total throughput scales linearly with pods and shards, because a decision touches exactly one tenant's key space and tenants are independent. Getting from 100k/s to 1M/s is 10× the pods and 4× the shards — arithmetic, not architecture.
Routing affinity is what makes it cheap. Hashing on org_id at the edge means a tenant's traffic lands on a small pod set, so leases are reused rather than re-fetched: measured lease hit rate rises from 78% with random routing to 92% with affinity.
The binding constraint is not total request rate. It is a single organisation's keys landing on one Redis slot, because that is the price of the atomicity in view 12. Tier 4 exists solely to relieve it.
Unit economics
1 limiterd pod ≈ 18k decisions/s on 4 vCPU and 2 GiB. 1M/s needs roughly 56 pods of headroom-free capacity, provisioned at 90 for burst and rolling updates.
1 Valkey shard ≈ 90k script executions/s, and only 8% of decisions reach a shard. 16 shards therefore cover well beyond 1M/s of decisions.
The shard count is driven by hot-tenant distribution and memory, not by aggregate throughput.
The hot-tenant trade
Above 5k rps a single organisation is split into 8 deterministic sub-shards, {org:acme#0..7}, and merged back after 5 minutes below the threshold.
Splitting divides the quota N ways, so overshoot for that tenant rises from about 0.9% to about 3%. That is the explicit cost of the split and it is recorded on the tenant's policy.
Sub-sharding is applied automatically on hot-key detection but is visible and overridable, because an automatic action that changes a tenant's enforcement accuracy should never be invisible to the operator.
