How long must you watch a freshly restarted long-lived service before a rising post-collection floor entitles you to call it retention?

## Why a rising floor is expected at first Restarting a service empties every structure it maintains. What follows is a genuine increase in the live set that has nothing to do with a defect: - **Caches fill.** A cache bounded by entry count or by an eviction horizon climbs toward that bound at whatever rate distinct keys arrive. If the horizon is long, the climb is long. - **Pools grow.** Connection pools, worker pools and buffer pools expand toward their configured or demand-driven steady size, and each element is reachable by design. - **Lazily built structures appear.** Anything constructed on first use — compiled patterns, prepared statements, per-endpoint metadata, internal maps keyed by whatever the traffic actually contains — enters the live set only when the traffic first exercises that path. - **Rare paths arrive late.** A structure built only by a nightly job or by one seldom-used endpoint raises the floor days after start-up, and it is not retention. The naive conclusion — "we restarted it four hours ago and memory is already up 300 MB, it is leaking" — is the single most common false positive in this material. ## The two requirements on the window 1. **Start after the slowest legitimate fill has settled.** The right number is not a habit like "skip the first ten minutes"; it is derived from the system. Ask what the longest-lived thing the service caches is, and how long a key has to be absent before it is evicted. The warm-up segment ends when that process has reached its bound, which may be minutes or may be most of a day. 2. **Span several complete traffic cycles, comparing like phases.** Most services have a daily rhythm, and the live set genuinely differs between peak and trough because in-flight work, per-connection state and per-session state are all reachable. Comparing this afternoon's floor with last night's produces a slope out of nothing. Compare the same hour across days. ## Deciding between fill and retention The test is the second derivative, stated in plain terms: **does the climb flatten?** | observation across the window | reading | |---|---| | rises, then decelerates into a level plateau | warm-up or cache fill, now at steady state | | rises at a roughly constant rate that survives several cycles | retention | | rises, plateaus, then rises again after a deploy or a new traffic pattern | a new steady state, then watch again | | rises and falls with the daily rhythm around a level mean | in-flight and per-session state, not retention | A practical routine on a fourteen-day chart: drop the warm-up segment, take one floor at the same hour on each remaining day, and fit a line. If the slope is inside the day-to-day variation you already see in the flat region, you are not entitled to call it retention yet; if the line holds its slope across a week, you are. Reporting it as a rate — "the floor is climbing about 90 MB a day, so from 1.2 GB it reached 2.1 GB in thirteen days" — is what makes the claim checkable by someone else. ## Complications worth naming - **Retention proportional to traffic.** If a service retains a little per connection, and connection counts follow the daily rhythm, the floor rises in a staircase whose steps match the load pattern. Same-phase comparison across days is exactly what separates that from healthy diurnal variation: the healthy one returns to the same nightly floor, the retaining one does not. - **Deploys reset the clock.** A deploy restarts warm-up, and a fleet that deploys daily may never run long enough to expose a slow leak. That is a real reason a leak survives for months, and a reason to keep one long-running instance out of the deploy rotation when investigating. - **A bounded cache still counts as memory.** Concluding "it plateaued, so there is nothing to do" can be wrong for capacity reasons even when it is right about retention; the plateau level itself may be too high for the room available. - **Do not restart to test.** A restart destroys the very series you need, and buys only as much time as the retention takes to rebuild. The short answer an interviewer wants: you are entitled to call it retention when the climb has outlived every process that legitimately fills memory, has survived several full traffic cycles measured at the same phase, and has not decelerated.