Cold-cache collapse

Why can a cold system not serve its way back to warmth?

The arithmetic came in cache stampede. What is new here is the self-reference. A system's steady-state capacity depends on accumulated hidden state: page cache, buffer pool, JIT profiles, connection pools, DNS and metadata caches, compiled query plans. Call the ratio C_warm / C_cold. For a read-heavy service it is commonly 10 to 100 times.

If normal traffic λ is larger than C_cold, the system cannot serve its way to warmth. Warming needs serving, and serving needs warmth. So a restart does not return the system to its initial condition. It returns it to the worst condition it can be in, while a backlog and a herd of reconnecting clients are already waiting. This is the hidden-state principle in its strongest form: not just hysteresis, but a capacity level that cannot be reached from the state the system is actually in.

Only one general escape exists: control the admission rate during warm-up. Let the system serve at a rate C_cold can sustain, and raise the rate as warmth builds. This needs a traffic control point upstream. That is why progressive readmission, slow-start in load balancers and half-open circuit probing all exist, and all have the same shape. Supporting moves:

• Staggered restarts, so warm peers carry the load and never more than a fixed fraction of the fleet is cold. This is the eviction cap, arriving from a different direction.
• Cache persistence or replay of a recorded working set, which turns warm-up from a serving problem into a bulk-load problem.

One sharp consequence: long uptime is a risk signal, not a reliability signal. A system that has not restarted in 300 days has an untested cold-start path, an unknown C_warm/C_cold ratio, and hidden state that nobody has listed. Regular restarts are how you find out whether you can restart.