A long-running in-memory store's resident size only ever grows between restarts, and only a restart returns it — how do you plan around that?

## Reframe the number as a rate A gap that only ever grows between restarts is not a value to inspect; it is a slope. Two quantities decide everything that follows: - **How fast it grows** — the increase in the gap per week under representative traffic. - **How much room is left** — the distance from current resident size to the machine or container limit. Divide one into the other and you have a runway in weeks. That single number converts an argument about whether fragmentation is "bad" into a scheduling question with a deadline, and it is the thing to establish before anyone proposes a remedy. A gap growing a few percent a month on a process with plenty of room is a note in a runbook; the same slope with weeks of runway is a piece of planned work. ## The three postures ### 1. Change the workload that produces the gap The gap is manufactured by something, and the something is usually visible: - **Bulk deletion.** A keyspace purged in one pass frees space faster than writes can consume it, everywhere at once. Deleting gradually lets ongoing writes reclaim the blocks continuously. - **Mixed value sizes in one keyspace.** Values that differ by an order of magnitude share memory badly, whichever allocation scheme is underneath. Splitting them across tiers removes the mechanism instead of managing it. - **Size migrations.** A change that rewrites every value at a new size is a one-off event with a permanent memory consequence; plan the restart with it rather than discovering the consequence afterwards. This is the only posture that reduces the slope rather than buying time against it, which is why it is worth exhausting first. ### 2. Let the store consolidate Some stores in this class can relocate live entries in the background so that whole regions empty and become returnable, and some can reassign an idle region to a size class that needs it. Where such a facility exists it reduces how often a restart is the only remedy, at a cost in serving time while it runs, since it is moving data the store is simultaneously trying to serve. Where it does not exist — and for a good part of this class it does not — this posture is simply unavailable, and a design that assumed it is a design with a hole in it. ### 3. Schedule the restart The blunt remedy always works. What makes it a principal-level answer is costing it honestly: 1. **What is lost.** Everything in the tier with no other copy — sessions, locks or leases, counters, deduplication records — is gone unless the store keeps something across restarts. Entries that are copies of durable data are only a cold-start cost. 2. **What the caller sees.** A period during which the tier is empty and every request behind it goes to whatever sits underneath, which is a load event for that system rather than a quiet moment for this one. 3. **In what order.** Where the topology has more than one copy, restarting so that a copy stays reachable narrows the window considerably, at the cost of a period with reduced redundancy. ## Choosing between them | Situation | The posture that fits | |---|---| | Runway is long and the slope is small | Track it; revisit at the next capacity review | | The gap traces to one identifiable workload | Change the workload; the slope itself is the defect | | The store can relocate and traffic has quiet periods | Consolidate in the background, off-peak | | Runway is short and the tier holds only copies | Plan a restart, accept the cold period | | Runway is short and the tier holds the only copy | Plan a restart **and** fix why the only copy lives here | That last row is the one worth saying out loud. A tier whose contents cannot survive a restart has made a routine memory-management remedy into a data-loss event, and the right conclusion is often not about memory at all. ## What not to do - **Do not treat the gap as a defect to be escalated** when its cause is a purge or a size shift. The report goes nowhere and the runway keeps shortening. - **Do not treat a growing gap as inevitable** either. "It is just fragmentation" is the sentence that precedes the operating system's out-of-memory kill, usually after a stretch of paging to disk that made the tier slow before it made it absent. - **Do not assume the gap behaves the same on every store.** Where memory is carved into fixed-size classes, the trapped space is counted inside the store's own total instead of in the gap, so the slope you are measuring may not be visible in the figure you are watching. Know which scheme is underneath before you build a plan on one number's trend. ## The shape of a good answer An interviewer is listening for the conversion of an open-ended memory observation into a decision with a date, a cost and an owner: here is the rate, here is the runway, here is what we change or when we restart, and here is what that restart costs the callers. Someone who has operated a volatile tier reaches for the runway first. Someone who has only read about it reaches for a tuning knob.