What makes a quiet-period stage emit nothing for an hour while its dial source is in constant use?

## The mechanism A quiet-period stage holds the most recent value and arms a timer for a fixed window. Every arrival does two things: it replaces the held value, and it cancels and rearms the timer. Release happens only when the timer reaches the end of the window uninterrupted. That gives a clean rule: **the stage emits only when the gap between two consecutive arrivals is at least the window.** If the source's gaps stay below the window, the timer is cancelled before it fires every single time, and the output is empty for as long as that continues. Nothing is queued, nothing is buffered, nothing will arrive later in a rush - a trailing quiet-period stage keeps exactly one value, and each new arrival overwrites it. The counter-intuitive part is the direction of the effect: a stage installed to reduce load produces *less* output the *more* active the source is, and can produce none. ## Why the symptom misleads On the graph, a starved stage looks exactly like a stalled pipeline: output flat at zero. Teams therefore reach for the usual stall explanations - a blocked worker, a slow consumer, a lost subscription - and none of them fit, because the stage is doing precisely what it was configured to do. Two cheap measurements separate the cases: - **Counters on both sides of the stage.** Healthy input with zero output is starvation. Zero on both sides is an upstream stall or a subscription that ended. Healthy input with *delayed* output is an ordinary latency problem. - **A histogram of gaps between arrivals, compared with the configured window.** If the window sits above nearly the whole distribution, starvation is arithmetic, not bad luck, and it will recur whenever the source is busy. ## Choosing a window from the distribution A quiet-period reduction only makes sense when the gap distribution has two modes with a valley between them: short gaps inside a burst, long gaps between bursts. The window belongs in that valley. - **Window above both modes** - the stage starves for as long as the source keeps producing. - **Window below both modes** - almost every value satisfies the window, and the stage degenerates into a pass-through that adds one window of latency for nothing. - **No valley at all** - the source has no bursts. No window is correct, and the reduction is the wrong one for this feed. Note that widening the window, the instinctive response to "I am getting too much output", makes starvation strictly more likely, because it raises the bar the source's silence has to clear. ## The two honest fixes | fix | what it changes | what it costs | |---|---|---| | pair the window with a maximum wait | the newest held value is forced out once it reaches a fixed age, even mid-burst | output is no longer only the settled value; the consumer may see mid-burst states | | switch to periodic sampling | emission is driven by the clock, so a busy source cannot suppress it | intermediate values between ticks are lost, including short-lived excursions | Both turn an unbounded wait into a stated staleness bound, which is the property the consumer actually cares about. Choose by asking what the consumer needs: the value the source settled on (keep the quiet period, add the ceiling) or a recent value at a predictable rate (sample). ## What to say in the postmortem Three things make the write-up useful rather than a shrug: 1. **The bound that was missing.** The stage had no upper limit on how long a value could be held. That is the defect, not the window value. 2. **The evidence.** The measured gap distribution against the configured window, showing the starvation was structural. 3. **The new promise.** A staleness bound the consumer can rely on, with an alert on output age rather than on output rate - a rate alert cannot distinguish "quiet source" from "starved stage", while an age alert fires on exactly the condition that hurt.