A fixed-cell object pool that grew during a traffic spike still holds those cells hours later. What design choices control that retention?

## Growth is a decision, not an accident A pool that may grow does so at exactly one moment: `acquire` is called, every cell is out on loan, and the code chooses to create another rather than wait or fail. The new cell is indistinguishable from the others afterwards. When load falls, the cells come back to the free set and stay there — reachable, reusable, and never reconsidered, because nothing in a plain pool ever forms the opinion that it has too many. The result is a pool **sized to its all-time peak concurrency**, and a process footprint that is a record of the worst minute the service has had rather than a description of what it is doing now. In a fleet this shows as memory that only ever ratchets upward and resets on restart, which is easy to misread as a leak. ## Why it is retention and not a leak The distinction matters because it changes the investigation. A leaked cell is one nobody returned: it is not on the free set, no borrower will give it back, and the pool drains until acquirers wait or fail. A retained cell is on the free set, available immediately, and costs only its bytes. The tell is the free set's own size — if it is large while throughput is low, the pool is retaining, not leaking. ## The four controls - **Hard cap.** The pool never exceeds N cells; when all N are lent out, acquirers wait or fail. This converts an unbounded memory response to a spike into a bounded, visible latency or error response — which is usually the trade you want, because the spike was going to exceed some limit either way and this one you chose. - **Idle eviction.** A cell unused for longer than a chosen period is discarded, subject to a **minimum floor** so the steady-state path never pays creation cost. The period must exceed the natural spike interval, or the pool discards cells shortly before it needs them again. - **Low-water shrink.** Over a window, record the smallest number of cells simultaneously in use; anything above that plus a margin is surplus and can be dropped at the end of the window. This adapts to a workload whose steady state changes across a day, and it is gentler than per-cell timers. - **No growth at all.** A fixed pool created at startup with backpressure for everyone else makes the footprint a constant and moves the spike's cost entirely into the queue. The failure mode is explicit, which for capacity-limited resources is often preferable to memory that grows quietly. | Control | Gives back | Costs | |---|---|---| | Hard cap | Bounded worst case | Waiting or failures during a spike | | Idle eviction | Footprint after the spike | Recreation cost when load returns | | Low-water shrink | Adapts to a changing baseline | A window's delay before it reacts | | Fixed size | A constant, predictable footprint | No headroom for an unusual burst | ## Two multipliers people miss 1. **Sharding.** Pools are often split per worker or per shard to avoid contention on the free set. A pool sharded 8 ways, each shard grown to 512 cells, holds 4096 cells even if total concurrency never exceeded 600 — because each shard grew to its own local peak and no shard can lend to another. Sharded pools need a global cap, not only a per-shard one. 2. **Cell size.** Retention is counted in bytes, not cells. A pool that grew by 200 cells of 64 KB is holding roughly 12.8 MB; the same 200 cells at 4 MB each is 800 MB. A cap expressed in cells hides this, so express it in bytes when cell size varies between deployments. ## What to measure before choosing Three series answer the question without guessing: cells in use over time, cells held over time, and the gap between them. A large, flat gap after a spike is pure retention and argues for eviction or a low-water shrink. A gap that closes and reopens repeatedly argues for a floor and a longer window, because trimming into that pattern pays recreation cost over and over. And a cells-in-use line that flattens exactly at the pool's size is the cap doing its job — at which point the interesting metric is the wait time at acquire, not memory at all.