A batch load writes ten million entries with the same lifetime, so every deadline lands in the same second — what happens inside the store?

## The moment itself costs nothing It helps to start with what does **not** happen. At the second all those deadlines pass, the store does no work. There is no wake-up, no queue drained, no pass triggered. Ten million entries simply become unservable: any read of one now reports a miss. Reported memory does not move, and serving latency does not change. What has changed is the store's internal accounting of reality: the dead population went from near zero to ten million in one instant, and every route that returns memory now has far more to do. ## How the population drains | route | behaviour under a mass deadline | effect on the memory graph | |---|---|---| | reclaim on access | fires only for entries someone reads; a batch nobody reads gets nothing | none | | the background sweep | finds dead entries far more often per sample, but the per-cycle budget is fixed | a slope, over many cycles | | reclaim under allocation pressure | fires when the store needs the room, and dead entries are given up first | a step, whenever pressure arrives | Two shapes fall out of that table: 1. **Sweep-driven store, entries nobody reads.** The pass now finds something dead almost every time it samples, which is as efficient as it gets, but it still only does its budget's worth of work per cycle. The backlog drains over many cycles, and while it does, reclaim work is competing for the same machine that answers requests. The memory graph slopes down over minutes rather than dropping at the deadline. 2. **Access-driven store, or no sweep at all.** Nothing drains. The full batch stays resident indefinitely, and the memory comes back only when the store needs the room. Neither shape is a defect. They are what the class does, and which one you get is a property of the store you chose — which is exactly why an answer that asserts one of them as "what happens" is wrong somewhere real. ## Why this is a sizing question, not a latency question The thing to take to a capacity plan is that **a batch's footprint outlives its deadline**. If ten million entries with a one-hour lifetime fit comfortably, that tells you nothing about whether a second batch written an hour later fits, because the first batch may still be entirely resident. On a tier that loads in waves, the worst case is several waves resident at once, all of them dead. The secondary effect is on the store's own work. Where reclaim competes with serving, a mass of dead entries means a period of elevated internal work that you did not schedule and cannot pace — which is why spreading the deaths out is worth doing even when the memory is affordable. ## What to do about it - **Vary the lifetime per entry.** Adding a small random spread — a few percent of the lifetime — turns one enormous dead population into a stream of small ones. The total reclaim work is identical; its distribution over time is not, and the distribution is the whole problem. - **Delete explicitly when the batch is genuinely finished with**, rather than letting a deadline do it. That returns memory on your schedule and makes the cost visible where you chose to pay it. - **Size for the batch surviving well past its deadline**, not for it disappearing at one. - **Do not reach for a shorter lifetime as the fix.** Entries die sooner and are reclaimed by the same unchanged routes, so the resident footprint barely moves. ## The answer that misses the point The most common wrong turn is to answer with what happens *outside* the store — the load that falls on whatever produced the data once its entries stop being servable. That is a real concern and a different subject with a different owner. The question here is about the store's own behaviour: a dead population appearing in one instant, draining at a pace nothing about the deadline controls, and a memory profile that stays at its peak long after the data stopped being useful.