realtime-websocketslisted

# Realtime and WebSockets ## Purpose Build realtime features that behave correctly when the connection drops — which it will, constantly, on mobile networks. The hard part is not the socket; it is the state after the reconnect. ## When to Use - Building live updates, chat, presence, collaborative editing, or streaming dashboards. - Choosing between WebSockets, SSE, and polling. - Scaling a socket server beyond one instance. - Diagnosing memory growth or dropped messages under load. ## Capabilities - Protocol selection and trade-offs. - Connection lifecycle: handshake, auth, heartbeat, graceful close. - Reconnection with resume tokens and gap backfill. - Horizontal scaling with a pub/sub fan-out layer. - Backpressure and slow-consumer handling. ## Inputs - Direction of data flow (server to client, or bidirectional). - Message volume, size, and acceptable latency. - Whether missed messages must be recovered or can be dropped. ## Outputs - A protocol choice with a stated reason. - A reconnect path that restores correct state, not just a live socket. - A scaling design that works with more than one server instance. ## Workflow 1. **Choose the simplest protocol that works** — Server-to-client only? Use SSE: it is plain HTTP, reconnects automatically, and passes through proxies. Bidirectional and low-latency? WebSockets. Infrequent updates? Polling is not embarrassing. 2. **Authenticate at the handshake** — Validate the token on connect; re-validate periodically for lon