Several city workers all wait exactly 2, then 4, then 8 seconds after timeouts to the same controller and stampede together when the window opens. Which pattern reduces that synchronized retry storm?
Select an answer to reveal the explanation.
Short Explanation
If every clerk returns at the exact same minute, the lobby floods again. Growing waits plus a little random jitter spreads them out so the counter can breathe.
Full Explanation
Synchronized retries happen when every worker uses the same deterministic backoff schedule (2s, 4s, 8s) and wakes together against the same controller. Exponential backoff with jitter grows the wait while adding randomness so city workers desynchronize, smoothing load when the window opens and reducing the stampede that re-triggers timeouts or 429s.
A fixed one-millisecond sleep with no growth and no spread keeps pressure maximal and synchronized. A shared sleep of zero forces permanent simultaneous retry forever. Replacing REST with a proprietary message-queue product as the only answer dodges the retry-pattern question; queues may help architecture later but do not explain how to pace HTTP retries on the exam’s terms.
Exam caveat: jitter should be applied on top of exponential growth (full or equal jitter variants)—exponential alone still herds if every client starts at the same failure instant. Operational check: inject timeout faults in a multi-worker test, plot retry timestamps, and confirm they fan out rather than align on exact 2/4/8-second boundaries against the shared controller. Full jitter (random delay in [0, capped exponential]) is a common pattern that breaks lockstep among municipal workers better than identical schedules. Combine jittered backoff with a shared process limiter when many jobs target one controller so desynchronization and admission control work together.