Realtime backend costs: WebSockets, polling and fan-out

Who is this for?

Mobile teams building chat, live status or collaborative workflows.

Before you start

Update frequency, channel structure and concurrent session estimates.

1. Define freshness

Specify the time between a server change and a visible device update. An order screen may tolerate seconds while collaborative editing may not. Record how many devices need updates concurrently. Offline clients still need a way to fetch current state later; a persistent connection is only one part of the contract.

2. Select a transport deliberately

WebSockets add connection management, heartbeat, permission and backpressure work. Polling can be simpler for slow-changing state but aggressive intervals produce unnecessary requests. Conditional HTTP can avoid sending unchanged response bodies without making server work free.

3. Estimate recipient fan-out

One event sent to 100 recipients involves 100 deliveries. An illustrative 10 events per second, 100 recipients each and 500-byte bodies produce 500,000 bytes per second before protocol overhead or retries. Restrict subscriptions using authenticated channel permissions, not just an obscure channel name.

Body traffic ≈ events/s × recipients/event × bytes/message
10 × 100 × 500 = 500,000 bytes/s before overhead

4. Recover after disconnection

Add jitter to reconnect backoff so a server restart does not synchronize all clients. Use event cursors or ordered identifiers to retrieve missing changes. An open socket does not prove every event was processed. Confirm important business effects against durable records.

5. Account for mobile lifecycle

Operating systems constrain background applications. Do not treat a foreground connection as a background delivery guarantee. Fetch current state on resume. Push can alert the user, while backend state remains authoritative. Avoid recording sensitive message bodies in connection logs.

6. Test beyond connection count

Measure delivery latency, queue growth, dropped events and reconnect rates. A slow client must not indefinitely grow its buffer or block other recipients. Define queue limits and disconnect behavior. Planned resource sizes do not imply a concurrency guarantee; test representative workflows before publishing capacity expectations.