backpressure-guard

Every fan-out loop makes an implicit promise: pushing an update to N connected clients takes roughly the same effort per client, and one client's problems stay that client's problems. That promise breaks the moment a real network is involved — a phone loses signal mid-send, a laptop sleeps with a socket still open, a browser tab freezes, an admin walks away leaving a dashboard idle for days. Two different failures follow from the same root cause, and a codebase can have either without the other: the loop can stall on one slow write and delay everyone behind it in iteration order (a throughput bug), or the state kept per connection — an outbound buffer, an ack-tracking map — can grow every time that one client doesn't keep up, with nothing ever shrinking it back down (a memory-exhaustion bug). Both are invisible in local testing and under light load; both are catastrophic in production once a fan-out list gets long enough or a stalled client sits around long enough.

This is a real, repeatedly reported bug class in production real-time systems, not a hypothetical. actix/actix-web issue #1967 (2021) documents the throughput half cleanly: the WebSocket client "accepts bytes without bound, such that it will consume infinite memory if the rate of bytes in exceeds the rate of bytes out" — a producer with no way to tell it's outrunning a slow consumer. socketio/socket.io issue #4984 (opened March 2024, in one of the most widely used real-time libraries in the ecosystem) documents the memory half with a real reproduction, not a guess: broadcastWithAck stores one entry per socket in a pendingAcks-style map keyed by message id, and if a client's connection stalls before it acknowledges, that entry was never cleaned up — the reporter's own test (500 clients across 50 rooms, one broadcast per room per second, clients simulating a stalled ack) showed memory climb to 1.5GB in three hours before the process would have gone down. The fix, shipped in socket.io@4.8.4, was exactly a timeout-triggered cleanup of the orphaned map entries — proof that "unbounded growth from a client that stops responding" is a real shape teams ship and have to patch after the fact, not a theoretical edge case.

Step 1: find every place code iterates live connections to push the same update

Grep for the fan-out shape itself: a loop or library call that walks a set/list/room of open connections and sends the same payload to each — for (const ws of subscribers) ws.send(...), a room/channel emit(), a pub/sub relay forwarding one message to many subscriber sockets, an SSE hub writing to every open response stream. List what each one feeds: a chat room, a live dashboard or ticker, presence/online indicators, collaborative-editing ops, an admin action's confirmation broadcast. Each of these is a candidate for steps 2–3.

Step 2: check whether one connection's send can stall delivery to the rest

For each fan-out loop found in step 1, look at how the per-connection send actually executes. A plain synchronous loop that calls a blocking or TCP-backpressure-sensitive send for each connection in turn has no isolation between connections: if one socket's underlying write can't complete immediately (the client is mid-reconnect, the OS socket buffer is full, the process is a stalled mobile connection), every subscriber later in iteration order waits behind it before receiving anything — worse the longer the subscriber list is. Isolation looks like: each send scheduled independently (fire-and-forget with its own error handling, a per-connection queue drained on its own timer/microtask), so one stalled write can't hold up the loop that's still iterating the rest.

Step 3: check whether the per-connection outbound path is actually bounded

Find what accumulates, per connection, when that connection doesn't drain fast enough or doesn't respond in time: a message array pushed onto with no cap, a library's internal write buffer (Node's ws, browser WebSocket.bufferedAmount, an actix WebsocketContext) that's never checked before queuing more, or the socket.io shape — a server-side map/table populated on every send and keyed by a message or ack id, only ever cleared by a response that may never come. Ask directly: is there a maximum queue depth, a high-water mark, or a bufferedAmount-style check anywhere on this path before another item gets added — or does nothing cap it at all? A for loop that calls .send() unconditionally, or a Map.set() with no matching Map.delete() reachable from anywhere but a successful response, is the shape to flag.

Step 4: check what happens when a client is confirmed slow, and whether that state ever gets reclaimed

Where step 3 finds no bound, check for any other path that eventually reclaims the growing state — a connection-close handler that clears that connection's queue, a timeout that expires a stale ack-map entry (the socket.io fix), a heartbeat/ping that detects and force-closes a dead-but-still-open socket. If one of those exists, the growth is bounded by however long a stall typically lasts, which is very different from no bound at all. If none exists, the growth genuinely has no ceiling: it only stops when the client eventually reconnects (releasing whatever was tied to the old connection) or the process runs out of memory first — the exact trajectory socket.io's own reporter measured.

Report

Lead with whichever applies: (a) a fan-out loop with no per-connection isolation (step 2), citing the exact send call and what blocks behind it; or (b) unbounded per-connection state with no cap and no reclaim path (steps 3–4), citing what accumulates and what should have cleared it. BLOCK for confirmed unbounded growth with no cap and no timeout/disconnect-based cleanup (the socket.io #4984 shape before its fix), or a synchronous/blocking send inside a shared fan-out loop with no per-connection isolation (one stalled client provably delays every other subscriber, worst on the longest fan-out lists). CAUTION for a bound that exists but is unverified or very high, or where overflow is capped but the policy on hitting it isn't defined (messages silently drop with no log, or the slow connection isn't closed so the next broadcast repeats the same problem), or isolation exists but nothing would surface a client that's chronically, quietly slow. SAFE only with evidence: a documented, enforced high-water mark or bufferedAmount check on the outbound path, a stated and correct action for hitting it (drop-oldest, drop-newest, or disconnect with a specific close code), and confirmation that one connection's send genuinely can't block delivery to the others.

Boundaries

• Not resync-guard's territory — that skill audits whether a client that reconnects after a gap resyncs the data it missed. This skill audits whether the live, currently-connected fan-out path stays healthy while a client is connected but slow: a resource-exhaustion/head-of-line-blocking bug, not a data-loss-on-reconnect one.
• Not job-warden's territory — server-side queue/cron idempotency and scheduling, not client-connection fan-out.
• Not a capacity-planning or connection-storm review — doesn't estimate how many concurrent connections a server can hold, or review reconnect-storm mitigation after a deploy (jittered backoff, load-balancer accept-queue tuning). It reviews the ongoing per-connection send path for a client that's already connected and subscribed.
• Not security-sweep's territory — doesn't assess whether a slow-consumer condition is being deliberately triggered by an attacker for denial of service; reviews whether ordinary slow or lossy clients (a phone on a bad connection, a frozen tab, a laptop that went to sleep) can degrade or crash the service, whatever caused the slowness.
• Can't measure real-world client-slowness distribution or the actual memory-growth rate from source alone — say so plainly when severity genuinely depends on production traffic patterns (how many clients, how often they stall, for how long), rather than guessing how fast the condition would bite.