Usage Metering & Billing Pipeline · View 21 of 22 · Assurance
The open decision
- Message 8 is question 3 of the requirement, answered one way and marked: the cap check fails open and records that it did, so the overshoot is known rather than invisible. The alternative — fail closed — trades unbillable usage for refusing a paying customer's request during a billing outage.
- The token is scoped to the producer's own meters, so authorisation is a property of the identity rather than a check in application code.
- The customer read path is authorised per account before any store is touched, not filtered after.
Assumptions
- Cap decision p99 ≤ 10 ms in-region with a better-than-95% cache hit rate (stated assumptions). If either is wrong, synchronous caps are not viable and enforcement becomes asynchronous.
- Entitlement availability ≥ 99.99% monthly, because the serving path may depend on it (stated assumption).
Risks
- Fail-open means a long entitlement outage produces usage nobody is entitled to. Bounding it needs a secondary local limit in the producer, which is not in the MVP.
- A balance read on cache miss puts the balance ledger on the request path at the worst possible moment: when the cache is cold after a deployment.