Your quota counters live on a tier that removes entries under memory pressure - how far over the quota can one subject go, and how do you bound that in advance?

## Absent means zero, and that is not a bug A period counter is created by the first call of the period. Before that call the key does not exist, and the enforcement code reads an absent key as a count of zero and allows the request. There is no way to write it otherwise: the tier cannot distinguish *this subject has not called yet* from *this subject's counter was removed twenty minutes into the period*. That is the whole failure. The removal is silent at the point where it matters. No error is raised, no branch is taken that differs from the ordinary happy path, and the subject is granted an entire fresh allowance in the middle of a period it had already exhausted. ## The size of the over-grant The intuition that a lost counter costs a few extra calls is wrong, and it is worth being explicit about the arithmetic. If the quota is *n* per period and the counter is removed *k* times during one period, the subject can be granted up to *n × (k + 1)* in that period. The tier does not remember that it removed anything, so each removal restores the full allowance rather than part of it. Worse, removals are not independent of the subject's behaviour. A subject making many calls holds a counter that is being touched constantly and is *also* contributing to the memory pressure that causes removals in the first place, which is one reason a heavy subject is a plausible repeat beneficiary rather than a statistical outlier. ## The four disappearances, and why they differ Removal under memory pressure is one cause of a zeroed counter. The others are worth separating because the answer differs: 1. **Removal under memory pressure.** Mid-period, unannounced, possibly repeated. This is the one you bound with capacity and placement. 2. **The deadline passing early.** If the lifetime was sized to the period instead of outliving it, or the clock the deadline is measured against differs from the one naming the period, the counter can end before the period does. 3. **A restart that kept nothing.** Every counter for every subject returns to zero at once - a population-wide over-grant for the remainder of the period. What survives a restart is a deployment choice: some keep nothing, some keep a periodic whole copy, some replay a log of writes, in which case the counter comes back but is behind by the loss span. 4. **A promoted copy that never received the increments.** Where a write is acknowledged before a copy holds it, a failover promotes a copy whose count is lower than the one callers were told about. Stores differ here and it is not a given: several in this class can be configured to acknowledge only once a copy has it, and some offer that per call, at the cost of latency on every increment. An answer that treats all four as *the counter was gone* misses that one is bounded by capacity planning, one by arithmetic on the lifetime, one by the durability posture, and one by the replication contract. ## Bounding it before it happens - **Keep the counters out of contention.** The counters are tiny and the pressure almost never comes from them; it comes from whatever bulk workload shares the tier. Separating the quota keyspace onto its own tier, or onto a deployment with its own ceiling, converts a shared risk into one you can size directly. - **Know which ceiling behaviour you are on.** Stores in this class do not all respond to a full tier the same way. Some remove entries to make room; some refuse writes instead. On the second kind the counter is never zeroed - the increment fails - which is a different and in some ways better problem, because it is visible. - **Decide fail-open or fail-closed, explicitly.** When the increment cannot be performed, enforcement either allows the request or refuses it. A protective quota in front of a fragile dependency usually wants to refuse; a courtesy quota on a public read endpoint usually wants to allow rather than take the product down because a tier is unwell. The point is that the decision is made once, deliberately, and not left to whatever the client library's exception path happens to do. - **Alert on the removal rate itself.** A tier steadily removing entries is telling you the quota is currently advisory. That signal is cheaper and earlier than trying to detect over-granted subjects after the fact. - **Say what the over-grant is worth.** If it is fairness or protection, one subject getting a second allowance occasionally is a priced degradation, and the honest answer is to accept and monitor it. If a second allowance means money, the counter is in the wrong home. ## What you should not claim Do not describe a counter on this tier as a hard cap. It is an enforcement mechanism whose accuracy degrades with the health of the tier, and the useful sentence in a design review is the bound - *a subject can exceed its quota by one quota per removal, we expect removals never, and we alert if any occur* - rather than a guarantee the tier does not provide.