Backpressure, heartbeats, and reconnects

A WebSocket that works on a laptop and fails in production usually fails in one of three ways. A slow client, a phone on a bad connection, stops reading, and the server keeps producing; the unsent bytes pile up in memory until something gives. A proxy between them decides a socket that has been quiet for sixty seconds is dead and closes it while the model is still thinking. Or the connection drops for an ordinary reason, the tab reconnects, and the half-finished answer is gone. None of these are bugs in your handler. They are the difference between a connection and a reliable one.

The three fixes fit together. A bounded outbound queue per socket turns "the server produces faster than the client reads" into a decision you make explicitly. A heartbeat task sends a ping on a schedule and gives up on clients that never answer. And a message sequence number plus a short replay buffer lets a reconnecting client ask for what it missed.