Bound the message flow

The board coalesces viewer-count updates and disconnects a client whose outbound queue exceeds a safe limit. This is a small part of a live service-status board that streams incidents without losing its ordinary HTTP foundation, but the boundary it creates affects everything that follows.

The classic browser WebSocket API queues outgoing data and exposes bufferedAmount, but it does not provide automatic backpressure for incoming messages. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

Watch for one shortcut in particular: trying to append every update to an unbounded array until memory or responsiveness collapses. It makes later failures harder to locate. Instead, set message and queue limits, coalesce replaceable updates, monitor buffered bytes, and define a slow-client policy. Prefer an implementation you can explain from the outside before optimizing it.

Keep the wider goal in view: Build a bidirectional operator channel with explicit messages, bounded queues, and observable connection state. A short observation with concrete evidence is more useful than a confident sentence with no reproduction path.

Throttle one client, send a burst of updates, and prove memory stays bounded and important incident events remain ordered. Hand the result to someone else and see whether the behavior is clear without an oral explanation.