Real-time features done right: sockets, queues and backpressure

Real-time is easy to prototype and easy to get wrong. The demo works with three users; production has three thousand and a flaky mobile network.

Pick the lightest transport that works

Server-Sent Events or long polling for one-way updates. WebSockets when the client genuinely pushes back. Do not reach for a full pub/sub mesh before you need one.

Treat the socket as a cache, not the source of truth

State lives in the database. The socket carries "something changed" and the client reconciles. When a client reconnects after a dropout it re-fetches — it never assumes it saw every message.

Queues absorb spikes

Writes go through a queue so a burst of orders or events does not knock over the database. Workers pull at a sustainable rate. Slow consumers get backpressure, not an unbounded buffer that eventually OOMs the process.

Operate it

• Heartbeats and automatic reconnect with jittered backoff.
• Per-connection and per-room limits.
• Metrics on queue depth, consumer lag and dropped connections — these are your early warning.