A counter must restart from zero each hour, and its first increment creates the entry; what must the caller get right?

## The reset is a disappearance, not a zeroing A counter that starts again each period is not reset by an operation that writes zero. It is reset by its **entry ceasing to exist**: the deadline passes, the entry goes, and the next change recreates it from nothing. That single fact produces every consequence in this answer, and it is the thing most candidates skip past. The mechanics of how a deadline is attached and enforced are a subject of their own. What belongs to the counter is narrower and more practical: the entry is the unit the deadline attaches to, and the entry is born from the first change. ## The gap between the change and the deadline On a store that creates a missing counter at zero, the first change brings the entry into being **without a lifetime**. Attaching one is a second operation, and only the caller that created the entry should do it — otherwise every subsequent change pushes the deadline further out and the period never ends. 1. Apply the change. 2. Look at the number handed back; if it indicates this was the first change, attach the deadline. 3. Every later caller does step 1 only. The failure lives between 1 and 2. If the process dies, is killed, or times out there, the entry exists with **no deadline** and no later caller will add one, because none of them sees a first change. The counter climbs for as long as the tier is up, every reading covers an unbounded period instead of an hour, and nothing anywhere reports an error. It is a silent, permanent defect in a counter that looks healthy. Two defences are worth naming: - Make the create and the deadline **one unit of work**, if the store offers a way to apply both together or to run the pair as a single server-side action; what is available varies across this class. - Failing that, have a reader that notices a counter with no deadline and attaches one, accepting that the first period will be long. ## Whether an ordinary change disturbs the deadline This is where an answer that assumes one store gets caught. The honest statement is that **it depends on the store and on the operation**: - Arithmetic against an existing entry is a modification and commonly leaves an existing deadline untouched. - A whole-value write may replace the entry outright and take the deadline with it, making the counter permanent. - Some stores offer a way to keep the existing deadline on an operation that would otherwise clear it. The practical rule that survives every variant: if **any** code path writes the counter key whole — a repair script, a reset job, a second service — it can quietly change whether the counter ever resets. Know the rule for your store, for each operation you use, and keep whole-value writes off counter keys. ## What the period boundary costs you | At the boundary | What is true | |---|---| | The old number | gone; the store keeps no history of an entry that expired | | A reader arriving after it | sees no entry, which it must read as zero, not as an error | | A total spanning the boundary | unrecoverable, unless something copied the number out first | | An early disappearance | indistinguishable from an ordinary reset | That last row is the one that matters on this tier. The entry can also disappear **before** its deadline — evicted under memory pressure, or lost with a restart — and it leaves exactly the same trace as a scheduled reset: nothing. A counter whose meaning depends on covering a full period can therefore be wrong at a moment nobody chose, and no reader can tell. If the previous period's number is needed, it has to be copied somewhere durable before the deadline, because afterwards there is nothing to copy. ## One deadline, one entry The deadline covers the entry, not the numbers inside it. If several counters are held as named fields of one entry, they share one lifetime and reset together; they cannot be given individual deadlines. Counters that need to reset on different cadences need separate entries — which also means separate per-entry overhead, and that cost belongs to the memory side of the design. ## Answering it well Lead with the reset being a disappearance. Name the creator's responsibility and the silent failure in the gap between the change and the deadline. Say explicitly that whether later operations disturb the deadline varies by store and by operation. Then close on what the boundary destroys: no history, and an early loss that looks exactly like a scheduled reset.