A daily quota per customer: how does anchoring the period to a shared clock rather than the customer's first call change the store?

## Two ways to say when the period starts *One thousand calls per day per customer* does not say what a day is. There are two answers, and they put the period's start in two different places. **Anchored to a shared clock.** A day means a named calendar day. The period identity is derived from the clock, so it can be written into the key itself: subject identifier plus period stamp. Every application instance computes the same key without consulting anything, and the counter is pure count. **Anchored to first use.** A day means twenty-four hours from this customer's first call. There is no agreed stamp to put in the key, so the period start has to be remembered - and the cheapest place to remember it is the counter's own **entry lifetime**. The counter is created on the first call with a fixed lifetime of one period, and the moment the store reclaims it is the moment the subject's allowance returns. ## What each one asks of the store | | anchored to a shared clock | anchored to first use | |---|---|---| | where the period start lives | in the key name, derived from the clock | in the entry's own deadline | | key shape | subject plus period stamp | subject only | | what the lifetime is for | housekeeping: stop the key leaking | the contract: it *is* the reset | | effect of losing the deadline | one leaked key, enforcement unaffected | the subject never gets a fresh allowance | | when subjects reset | all at the same instant | staggered, one per subject | | can support state the reset time? | yes, from the calendar | only by reading the entry's remaining life | The fourth row is the one that catches teams out. Under shared-clock anchoring, a missing deadline is the leak described elsewhere in this subject - unpleasant but not a correctness bug, because the *next* period uses a different key anyway. Under first-use anchoring, the deadline is the only thing that ends the period, so an undated counter means a customer that hits its quota is refused permanently. The same missing line of code has two entirely different severities. ## The lifetime kind matters here, and only here A lifetime can be **fixed, counted from the write**, or **access-extended, pushed forward by each use**. On a period counter the second is always wrong, and the failure is worth being able to state out loud: every request extends the deadline, so an active subject's counter never reaches it, the period never ends, and once the count crosses the quota that subject is refused for as long as it keeps trying. The subject is punished for exactly the behaviour the quota was meant to shape. The trap is that you can arrive at an access-extended lifetime without choosing it. On stores where writing an entry replaces it outright and discards whatever deadline it carried, a code path that re-dates the counter on every increment - added, usually, to fix the undated-counter bug - silently converts a fixed lifetime into an extended one. Stores differ in whether an ordinary write preserves an existing deadline, so this is a property to check on the store you actually run rather than to assume. ## The operational shape of a shared boundary Shared-clock anchoring has a second-order consequence in the store. Every subject's counter is created in the same small stretch of time after the boundary, and every one of them carries a deadline that falls in the same small stretch a period later. The tier therefore sees a synchronised creation burst and a synchronised reclaim, once per period. For a daily period on a modest subject population this is invisible. For a per-minute period across a large population it is a recurring shape in the tier's write rate and resident size, and it is worth knowing it is the enforcement design causing it rather than the traffic. First-use anchoring spreads both events across the period by construction, because each subject's clock started whenever it happened to arrive. ## Which to choose Choose the one the product promised, because the reset moment is user-visible and support will be asked about it. A quota described on a pricing page as *per day* implies a calendar reset that a customer can plan around; a quota described as *per rolling twenty-four hours* implies first use. One honest warning about each. Shared-clock anchoring concentrates the reset, so the most eager subjects re-arrive together at the boundary - the allowance returns for everybody at once. First-use anchoring makes every subject's reset unexplainable without inspecting the store, which is a support burden and an audit problem, and it means two subjects with identical usage can be treated differently depending on when they happened to start. What neither anchoring changes is the counter's dependence on the tier. Both hold a number that exists nowhere else, and both return to zero if that entry disappears before its period ends. ## What the period key has to carry Three things, and leaving any one out is a different failure: - **the subject** the allowance belongs to, at the granularity the allowance is written in — per account is not per user, and per user is not per device; - **the period**, encoded so that two adjacent periods cannot collide and so that reading the key tells you which period it is — a truncated timestamp does both; - **the allowance's identity**, where one subject has several — a read allowance and a write allowance that share a key silently spend each other's budget.