Tech News
← Back to articles

How to Make Things Slower So They Go Faster

read original related products more articles

Synchronized demand is the moment a large cohort of clients acts almost together. In a service with capacity $\mu$ requests per second and background load $\lambda_0$, the usable headroom is $H = \mu - \lambda_0 > 0$. When $M$ clients align—after a cache expiry, at a cron boundary, or as a service returns from an outage—the bucketed arrival rate can exceed $H$ by large factors. Queues form, timeouts propagate, retries synchronize, and a minor disturbance becomes a major incident. The task is to prevent such peaks when possible and to drain safely when they occur, with mechanisms that are fair to clients and disciplined about capacity.

The phenomenon has simple origins. Natural alignment comes from clocks and defaults—crons on the minute, hour‑aligned TTLs, SDK timers, people starting work at the same time. Induced alignment comes from state transitions—deployments and restarts, leader elections, circuit‑breaker reopenings, cache flushes, token refreshes, and rate‑limit windows that reset simultaneously. Adversarial and accidental alignment includes DDoS and flash crowds. In each case the system faces a coherent cohort that would be harmless if spread over time but is dangerous when synchronized.

How failure unfolds depends on which constraint binds first. Queueing delay grows as utilization approaches one, yet many resources have hard limits: connection pools, file descriptors, threads. Crossing those limits produces cliff behavior—one more connection request forces timeouts and then retries, which raise arrivals further. A narrow spike can exhaust connections long before CPU is saturated; a wider plateau can saturate CPU or bandwidth. Feedback tightens the spiral: errors beget retries, retries beget more errors. Whether work is online or offline matters, too. When a user is waiting, added delay is costly and fairness across requests matters; when no user is waiting, buffering is acceptable and the objective becomes sustained throughput.

A useful way to reason about mitigation is to make the objective explicit. If $M$ actions are spread uniformly over a window $[0, W]$, the expected per‑bucket arrival rate is $M/W$ (take one‑second buckets unless your enforcement uses a different interval) and the expected added wait per action is $W/2$. Their product is fixed,

$$ \left(\frac{M}{W}\right) \cdot \left(\frac{W}{2}\right) = \frac{M}{2}, $$

so lowering the peak by widening $W$ necessarily increases delay. The design decision is where to operate on this curve, constrained by safety and product requirements. Under any convex cost of instantaneous load—capturing rising queueing delay, tail latency, and risk near saturation—an even schedule minimizes cost for a given $W$. Formally, with rate $r(t) \geq 0$ on $[0, W]$ and $\int_0^W r(t) , dt = M$, Jensen's inequality yields

$$ \int_0^W C(r(t)) , dt \geq W , C\left(\frac{M}{W}\right), $$

with equality at $r(t) \equiv M/W$. Uniform jitter is therefore both optimal for peak reduction among schedules with the same $W$ and equitable, because each client draws from the same delay distribution.

Translating principle into practice begins with the bounds your system must satisfy. Deterministically, the headroom requirement $M/W \leq H$ gives $W \geq M/H$, and Little's Law for extra in‑flight work gives $(M/W) \cdot s \leq K \Rightarrow W \geq Ms/K$, where $s$ is a tail service time (p90–p95) and $K$ the spare concurrency budget. Expectation is not enough operationally, because bucketed counts fluctuate even under a uniform schedule. To bound the chance that any bucket exceeds headroom, size $W$ so $\Pr{N > H} \leq \varepsilon$ for bucket counts $N$ modeled as $\text{Poisson}(\lambda)$ with $\lambda = M/W$ when $M$ is large and buckets are short. For $H \gtrsim 50$, a continuity‑corrected normal approximation gives an explicit $\lambda_\varepsilon$:

$$ \frac{H + 0.5 - \lambda}{\sqrt{\lambda}} \gtrsim z_{1-\varepsilon} \quad \Rightarrow \quad \lambda_\varepsilon \approx \left(\frac{-z_{1-\varepsilon} + \sqrt{z_{1-\varepsilon}^2 + 4(H + 0.5)}}{2}\right)^2, \quad W \geq \frac{M}{\lambda_\varepsilon}. $$

... continue reading