Realtime & WebSockets

01Polling, long-polling, SSE and WebSockets

Polling is asking 'anything new?' every few seconds. It is simple and works everywhere, but wastes requests and adds delay. Long-polling keeps each request open until the server has news or a timeout hits, then the client reconnects; less waste, more complexity. Server-Sent Events (SSE) keep one HTTP response open and the server streams text events down it; it is one-way (server to client), reconnects automatically and works well through proxies and HTTP/2. WebSockets open a full two-way channel over a single TCP connection, ideal when the client also sends frequent messages, as in chat, collaborative editing or games. Rule of thumb: polling for rare updates, SSE for server-to-client feeds such as notifications or AI token streaming, WebSockets for interactive two-way traffic.

02How a WebSocket connection works

A WebSocket starts as a normal HTTP request asking to upgrade the protocol. If the server agrees, it replies 101 Switching Protocols, and from then on the same TCP connection carries WebSocket frames instead of HTTP. Frames are small packets: text or binary data frames, plus control frames for ping, pong and close. Client-to-server frames are masked. Ping and pong keep the connection alive and detect dead peers. Because the upgrade is HTTP, the connection passes through load balancers and reverse proxies, but they must be configured to allow the upgrade and long-lived connections. Use wss:// (TLS) in production, always.

1GET /ws HTTP/1.1
2Host: api.example.com
3Upgrade: websocket
4Connection: Upgrade
5Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
6Sec-WebSocket-Version: 13
7 
8HTTP/1.1 101 Switching Protocols
9Upgrade: websocket
10Connection: Upgrade
11Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

03socket.io: namespaces, rooms and auth

socket.io is a library on top of WebSockets that adds automatic reconnection, acknowledgements, fallback to long-polling, and a simple model for grouping connections. A namespace (like /staff or /customers) is a separate channel with its own middleware, useful for different audiences. A room is a group inside a namespace; the server adds sockets to rooms and emits to the whole room at once. Typical rooms: one per tenant, per branch, per terminal and per user. Authenticate in the handshake middleware, before the connection is accepted, and decide room membership on the server from the verified identity. Never let a client join a room just because it asked.

1io.of('/staff').use(async (socket, next) => {
2  try {
3    socket.data.user = await verifyAccessToken(socket.handshake.auth.token);
4    next();
5  } catch {
6    next(new Error('unauthorized'));
7  }
8});
9 
10io.of('/staff').on('connection', (socket) => {
11  const { companyId, branchId, sub } = socket.data.user;
12  socket.join(['company:' + companyId, 'branch:' + branchId, 'user:' + sub]);
13});
14 
15// elsewhere, after an order changes:
16io.of('/staff').to('branch:' + order.branchId).emit('order.updated', { id: order.id, status: order.status, version: order.version });

04Scaling across servers with Redis

One process only knows its own connected sockets. When you run four API instances, a user connected to instance A will not see an event emitted on instance B. The fix is a shared message bus. The socket.io Redis adapter publishes every room emit to Redis pub/sub; each instance subscribes and delivers to its local sockets. If you use socket.io's long-polling fallback behind a load balancer, enable sticky sessions so a client's requests reach the same instance; with WebSocket-only transport this is not needed. For very large fan-out or guaranteed delivery, Redis Streams or a sharded adapter are options. Also emit from background workers through the same adapter (the socket.io emitter package), so a queue job can notify users directly.

1import { createClient } from 'redis';
2import { createAdapter } from '@socket.io/redis-adapter';
3 
4const pub = createClient({ url: process.env.REDIS_URL });
5const sub = pub.duplicate();
6await Promise.all([pub.connect(), sub.connect()]);
7 
8io.adapter(createAdapter(pub, sub));

05Laravel: broadcasting with Pusher, Reverb and Echo

Laravel has broadcasting built in. You mark an event with ShouldBroadcast, define which channel it goes to, and Laravel sends it through a driver. Pusher is a hosted service: no servers to run, you pay per connection and message. Reverb is Laravel's own first-party WebSocket server speaking the Pusher protocol, so you can self-host with the same client code. php artisan install:broadcasting sets things up. On the frontend, Laravel Echo subscribes to channels. Private and presence channels are authorised in routes/channels.php: Echo calls the /broadcasting/auth endpoint and your callback decides whether this user may listen. Queue your broadcasts so a slow socket server never slows the HTTP response.

1// routes/channels.php
2Broadcast::channel('orders.{orderId}', function (User $user, int $orderId) {
3    return Order::whereKey($orderId)->where('customer_id', $user->id)->exists();
4});
5 
6// Frontend (Echo)
7echo.private('orders.' + orderId)
8    .listen('OrderStatusChanged', (e) => updateStatus(e.status));

06Reconnection, ordering and missed messages

Mobile networks drop constantly, so design for disconnection. Clients reconnect with exponential backoff and jitter, so a server restart does not cause a stampede of thousands of simultaneous reconnects. Events sent while a client was offline are lost in plain pub/sub. Treat the socket as a 'something changed' signal and the REST API as the source of truth: on reconnect, refetch current state. Include a version number or timestamp in each event so the client can ignore stale or out-of-order updates. If order matters for one entity, route its events through a single channel and process them sequentially. For critical data, use acknowledgements or a persisted event log with a 'since' cursor.

• Keep payloads small: ids and status, not whole objects.
• Send heartbeats; close and clean up dead connections.
• Configure proxy timeouts (nginx proxy_read_timeout) above your ping interval.

07Capacity: file descriptors, proxies and heartbeats

Every open WebSocket is an open file descriptor on the socket server and on every proxy in front of it. Linux limits these per process, often to 1,024 by default, so the first scaling wall is usually 'too many open files', not CPU. Raise the limit for the service (ulimit -n, LimitNOFILE in systemd, minfds in supervisor), and in nginx raise worker_connections and worker_rlimit_nofile, remembering that a proxied socket uses two connections in nginx: client side and upstream side. Memory per connection is the next limit, so measure it under load. Proxies close idle connections: nginx's proxy_read_timeout defaults to 60 seconds, and socket.io pings every 25 seconds by default, so the timeout must stay above the ping interval. Laravel Reverb has a specific trap: its default stream_select loop is limited to about 1,024 connections, and you need the ext-uv extension beyond that.

1map $http_upgrade $connection_upgrade {
2    default upgrade;
3    ''      close;
4}
5 
6server {
7    location /socket.io/ {
8        proxy_pass http://127.0.0.1:3001;
9        proxy_http_version 1.1;
10        proxy_set_header Upgrade $http_upgrade;
11        proxy_set_header Connection $connection_upgrade;
12        proxy_set_header Host $host;
13        proxy_read_timeout 75s;   # above the 25 s ping interval plus timeout
14        proxy_send_timeout 75s;
15    }
16}

08Delivery guarantees: acknowledgements and state recovery

A plain emit is fire-and-forget: if the socket dropped a moment ago, the message is gone. socket.io offers two tools. Acknowledgements let the receiver confirm processing, and emitWithAck with a timeout turns that into a Promise you can await, so the server knows whether a till actually printed a receipt and can retry through a queue if not. Connection state recovery lets a client that reconnects within a window, two minutes by default, get back its id, rooms and the packets it missed. It has limits: it only covers short disconnects, it is not supported by every adapter (the classic Redis pub/sub adapter does not support it; the Redis Streams adapter does), and by default it skips your auth middleware on recovery, which you may want to turn off. For anything that must never be lost, a persisted event log with a cursor remains the reliable answer.

1const io = new Server(httpServer, {
2  connectionStateRecovery: {
3    maxDisconnectionDuration: 2 * 60 * 1000,
4    skipMiddlewares: false, // re-run auth on recovered connections
5  },
6});
7 
8try {
9  const replies = await io.to('terminal:' + terminalId)
10    .timeout(5_000)
11    .emitWithAck('receipt.print', { orderId });
12  logger.info({ replies }, 'terminal confirmed');
13} catch {
14  await printQueue.add('retry', { orderId, terminalId }); // no ack in time
15}

09Fan-out, hot rooms and throttled updates

Fan-out is one event delivered to many sockets. A room with 50,000 viewers of a live dashboard turns one emit into 50,000 writes, multiplied across instances by the adapter. Three techniques keep this sane. Coalesce: instead of sending every change, keep the latest state per entity and flush at most every few hundred milliseconds, so 40 stock updates per second become two messages. Use volatile emits for data where only the newest value matters, such as cursor positions or live metrics: socket.volatile.emit drops the packet if the client is not ready rather than buffering it. Keep payloads small, ids and changed fields only, and consider a binary parser such as msgpack for high volume. For many instances, socket.io's sharded Redis adapter uses Redis 7 sharded pub/sub so traffic is spread across a Redis Cluster instead of every node receiving every message.

• Measure messages per second per room and per instance, not just connection count.
• perMessageDeflate compression is off by default in socket.io; it costs memory per socket, so enable it only when payloads are large.
• Very hot rooms can be split by region or shard, with clients joining one shard.

10Security of long-lived connections

WebSockets bypass some protections you rely on for HTTP. Browsers send cookies with the WebSocket handshake, but CORS does not apply to it, so a malicious page can open a socket to your server with the user's cookies: cross-site WebSocket hijacking. Always check the Origin header against an allow-list when using cookie auth. A token verified at connect time may expire hours before the connection closes, so schedule a disconnect at token expiry or require the client to refresh and re-authenticate over the socket. Treat every incoming message like an HTTP request body: validate it with a schema, check permission for the specific action, and rate limit messages per socket. Cap message size, since socket.io accepts up to 1 MB per message by default, which is far more than most apps need.

1const io = new Server(httpServer, {
2  maxHttpBufferSize: 64 * 1024, // default is 1 MB
3  allowRequest: (req, cb) => cb(null, ALLOWED_ORIGINS.has(req.headers.origin ?? '')),
4});
5 
6io.on('connection', (socket) => {
7  const expiresInMs = socket.data.user.exp * 1000 - Date.now();
8  const timer = setTimeout(() => socket.disconnect(true), expiresInMs);
9  socket.on('disconnect', () => clearTimeout(timer));
10 
11  socket.on('cart.update', (raw, ack) => {
12    const msg = CartUpdateSchema.safeParse(raw);
13    if (!msg.success) return ack?.({ error: 'invalid_payload' });
14    // permission check, then handle msg.data
15  });
16});