WebSockets

Overview

WebSockets upgrade an HTTP connection into a persistent, full-duplex channel. Either side can send frames at any time with just a few bytes of overhead, which suits interactive features that would be clumsy over request-response.

How it works

The client sends a GET with Upgrade: websocket; the server replies 101 Switching Protocols. From then on both sides exchange frames.

client                    node A        backplane      node B
  |--- upgrade ---------->|
  |<-- 101 ---------------|
  |--- msg to room 7 ---->|--publish---->|--deliver--->| other users

Since a user is connected to one node, messages for room 7 are published to a backplane, and each node forwards to its local subscribers. Authenticate during the handshake, then authorise each message. Track a sequence number per stream so a reconnecting client can ask for messages after the last one it saw.

Pitfalls

• No heartbeats. Half-open connections look alive; send ping frames and drop silent peers.
• Rolling deploys that kill thousands of sockets at once. Drain gradually and add jittered reconnect delays.
• Unbounded send queues for slow clients. Apply backpressure or disconnect them.
• Assuming delivery guarantees. Add ids, acknowledgements and idempotent handling.
• Per-connection memory and file descriptor limits; load test connection counts.

Key takeaways

• Use for genuinely bidirectional, low-latency traffic.
• Scale with a pub/sub backplane, not sticky assumptions.
• Build heartbeats, resume and backpressure yourself.
• Prefer SSE or webhooks when one-way is enough.
• Measure it in production: track latency, error rates and volume for this pattern, and review the numbers regularly so that limits and timeouts stay matched to real traffic.