Your product both throttles free users and bills paid users by call volume - which of those counts may live only on the volatile tier?

## Two counters that look the same in the code A throttle counter and a metering counter have the same shape: a key naming a subject and a period, raised by a **server-side increment**, given a lifetime so it does not outlive its usefulness. Reviewing the diff, you cannot tell them apart. The decision about where each belongs therefore cannot be made from the mechanism - it has to be made from what happens when the entry is not there. ## The test: price the zero Ask one question of each counter: *this number silently returns to zero mid-period - who notices, and what does it cost?* | | throttle count | metered billing count | |---|---|---| | what the number is | an input to a decision made now | a claim on money, made later | | who reads it after the period | nobody | finance, the customer, possibly an auditor | | cost of a return to zero | one extra allowance for one subject | an invoice that is wrong and cannot be defended | | cost of counting twice | a subject refused slightly early | the customer is overcharged | | can it be reconstructed? | pointless - the period has passed | it must be, from the underlying events | | honest home | the volatile tier | a durable store, written on the work path | The *reconstructible* row is the one that decides it. A throttle count has no meaning once its period ends, so there is nothing to rebuild. A billed count must be defensible - and if the only place it ever existed was a tier that acknowledges a write before any copy holds it, or that can be restarted empty, there is no artefact to rebuild it from and no way to answer a dispute. ## Why the tier cannot be quietly upgraded into the record The tempting move is to keep the metering counter on the volatile tier and make the tier more durable - keep a periodic whole copy, or replay a log of writes, or wait for a copy to acknowledge. Each of those genuinely narrows the loss span, and none of them closes it, because: - a count that survives a restart but is behind by the loss span is a *wrong invoice* rather than a missing one, which is worse: nothing signals that it is wrong; - accuracy for money needs both halves - never losing a count and never counting twice - and a retried increment after an uncertain failure adds one again. An increment is not idempotent, so a caller that cannot tell whether its increment landed cannot safely repeat it; - those postures cost latency or memory on *every* increment, to make a slow-path artefact slightly less wrong. The structural answer is that money is counted from a record of the individual chargeable events, and the total is derived from that record. Then a lost total is an inconvenience rather than a loss, because the events are still there. ## What the tier is still good for here None of this evicts the tier from the design. On the work path you write the durable record, and the volatile tier holds a fast, shared, approximate view - remaining allowance for the current period, the number a response header or a dashboard shows, the value a soft warning at eighty percent is compared against. Two properties follow and should be said out loud in a design review: 1. That value is now **a copy of data that lives somewhere else**, so it may be rebuilt from the durable record at any time, and the design of that copy - how it is refreshed, what a stale read costs - is a different subject with its own rules. 2. Because it is a copy, its disappearance is a degradation and not a loss: the fast path falls back to the durable store, slower and more expensive, and the product keeps working. That inversion is the point. The workload that *must not vanish* is moved to a home where it does not, and what remains on the tier is something whose loss you have already priced. ## The judgment, stated as a principal would state it The boundary is not *billing versus throttling*; it is *is this number read again after its period, by someone who can dispute it*. Counts that fail that test and therefore need a durable home include usage that converts to money, consumption of a prepaid balance, and anything a regulator or a contract can ask you to evidence. Counts that pass it - and belong on the tier precisely because they are cheap, shared and disposable - include protective limits in front of a fragile dependency, fairness allowances between tenants, and soft limits whose entire purpose is to be enforced now and forgotten. One genuinely hard case sits between them: a hard spend cap, where exceeding the limit costs the *company* money. It has the throttle's latency requirement and the invoice's accuracy requirement. The usual resolution is to enforce a deliberately conservative limit on the tier for speed, and to reconcile against the durable record on a short cycle, accepting that the cap is approached approximately and enforced exactly only on that cycle. Whichever way it goes, the interesting part of the answer is naming which of the two properties you chose to weaken.