Exponential backoff with jitter on client reconnection, not fixed retry interval
Why it matters
When a server restarts or drops a connection, every client attempts to reconnect. If all clients retry at the same fixed interval — say, 5 seconds — they form a synchronized stampede that hits the server simultaneously on each retry cycle. This thundering-herd effect can prevent the server from recovering under its own load. Jitter randomizes reconnect timing so the server receives a spread of reconnect requests it can absorb incrementally. ISO 25010 reliability includes resistance to self-inflicted load spikes of exactly this type.
Severity rationale
High because synchronized fixed-interval retries across many clients produce a thundering-herd stampede that can prevent server recovery after an outage.
Remediation
Implement exponential backoff with additive jitter on the client, capped at a maximum delay to prevent indefinitely long waits.
const MAX_BACKOFF = 30_000; // 30 s
let attempt = 0;
function scheduleReconnect() {
const base = Math.min(1_000 * 2 ** attempt, MAX_BACKOFF);
const jitter = Math.random() * base;
setTimeout(() => socket.connect(), base + jitter);
attempt++;
}
socket.on('disconnect', scheduleReconnect);
socket.on('connect', () => { attempt = 0; });
If you use Socket.IO's built-in reconnection, set reconnectionDelayMax and randomizationFactor rather than implementing your own loop — the default reconnectionDelay of 1 s without jitter is a partial fix only.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Real-Time Communication Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · reliability.recoverability — Recoverability
Taxons
History
- 2026-04-18·v1.0.0·Initial import from community-realtime·automated