Realtime Feature Patterns

The Poll-or-Subscribe Decision

Both approaches move updates to the user; they differ in who pays and when. Polling charges the client request budget and adds latency equal to roughly half the interval. A subscription charges server memory and connection state and delivers in milliseconds. Neither is free, so the choice follows data shape, not fashion.

Three questions settle most design reviews:

1. How often does data change per viewer? Below one change per 30 seconds, a 15-second poll costs the user almost nothing and the server nothing persistent.
2. How fresh must it be? If a 3-second-old number is acceptable, poll. If a missed 200 ms bid loses an auction, push.
3. What does holding a connection cost? Each open stream pins memory, a timer or cursor, and a slot in your connection table. Ten thousand simultaneous dashboards is a capacity plan, not a detail.

The arithmetic is worth saying out loud. One client polling every 5 seconds issues 17,280 requests a day; the equivalent subscription issues one request and then holds memory for all 24 hours. Rare, bursty data favors polling; dense, continuous data favors a stream.

Polling also wins on operations: no reconnect logic, no broker, no half-open sockets, and horizontal scaling is just more stateless instances. "Ship it with polling and add subscriptions when the numbers justify it" is a defensible plan for a weekly digest and a bad one for a chat product.

Features That Earn a Stream

Four patterns account for most production subscriptions, and each carries its own scoping rule.

1. Chat and threaded messaging. messageAdded(roomId:) is the canonical case: high frequency, tight freshness, and a natural key the client already holds. The resolver shape lives in subscription lifecycle; the design question here is what happens to messages sent while a user was away — a stream is not history, so the room still needs a paginated query on rejoin.

2. Live dashboards. Widgets do not need raw event rates; they need a tick:

subscription Dashboard($fleet: ID!) {
  dashboardTick(fleetId: $fleet) {
    at
    metrics { cpuP95 queueDepth errorRate }
  }
}

A server-side aggregator batches upstream churn into one tick per second, so subscriber count stops correlating with event rate. Batching on the client is the trap: multiplying every raw event by ten thousand subscribers is exactly the fan-out you were trying to avoid.

3. Notifications and inbox badges. Low frequency, but users notice a stale badge immediately — the badge often is the product. Polling a badge every 10 seconds per user is the classic waste case: thousands of requests an hour to deliver a handful of updates.

4. Presence and collaboration. Cursors, typing indicators, who is viewing a document. This state exists only while connections do; there is no row to poll, so a stream is the only faithful transport. It also means presence must decay on disconnect — a client that vanishes without unsubscribing would otherwise appear online forever.

What they share

Every one scopes by a key the client already knows — room, fleet, user, document — and refuses anything unscoped. An open messageAdded that streams every message in the system is simultaneously a performance problem and a data leak, which is the shape interviewers like to ask you to defend against.

Fan-out, Connect-Time Auth, and Cost

A single instance fans out to its own subscribers with an in-process map. Two instances cannot share that map, so a publish arriving on one node must reach subscribers sitting on another:

publisher --> [ broker: Redis / Kafka / NATS ]
                 |              |
            instance A      instance B
            local subs      local subs

Each instance subscribes to a topic once and delivers only to connections it owns. Never route publishes through the load balancer and never rely on sticky sessions to keep subscribers together — a redeploy moves them anyway, which is precisely when delivery matters most.

Authorization belongs at the handshake

// graphql-ws connection_init payload, or the SSE Authorization header
const user = await verifyToken(connectionParams.authorization);
if (!user) throw new Error('UNAUTHORIZED'); // reject before any subscribe is accepted

Checking authorization only when a subscribe message arrives leaks in two ways. A revoked token keeps delivering on a stream opened before revocation, because no new message ever triggers the check. And a client that passes once can hold the stream open while its permissions change underneath. Establish identity at connect time, re-check sensitive topics per event as defense in depth, and close streams when access is revoked — the revoke path is what teams forget to write.

Putting a number on it

A WebSocket costs roughly 2-10 KB of server memory plus a file descriptor, held for minutes; an HTTP request costs nothing once it returns. That asymmetry is why connection counts belong on the capacity dashboard next to CPU, and why per-client stream caps are a scaling feature rather than a courtesy. A deploy that doubles connections while halving traffic per connection still fails if the connection table is the constraint.

Interview framing: name the three axes that decide poll versus push (change rate, freshness tolerance, connection cost), then describe broker fan-out and the connect-time auth check as the two things that make a subscription design production-ready.