Skip to content
Optimal Lab

System design · interactive

Real-time: polling, SSE and WebSockets

Four chat messages arrive on the server at 3, 4, 19, 42 seconds. How quickly does each reach the browser, and how many requests does that cost over a minute?

0 s60 s

Amber: message arrives at the server. Bar: wait until the browser has it. Lines: polls.

Avg delay
5.5 s
Requests/min
6
Connection
new request each poll
Direction
separate POSTs

Simple and cache-friendly, but messages wait up to 10 s, and 6 requests a minute per user mostly return nothing.

Transport

Step 1 of 4

  1. 1

    Polling: ask on a timer

    Easy, but there's a trade-off between delay and wasted requests.

    Fine for things that change every few minutes.

  2. 2

    Long polling

    The server waits to answer until there's news, then the client asks again.

    Works through every proxy.

  3. 3

    SSE for one-way, WebSockets for two-way

    SSE is plain HTTP with built-in reconnects. WebSockets allow either side to send at any time.

    Both hold a connection per user.

  4. 4

    Fan-out and presence

    Servers subscribe to a pub/sub channel (Redis, NATS) so a message reaches users connected to other servers. Heartbeats track who's online.

    Pusher, Ably, Socket.IO.

In production

Tools and technologies

Real-time services wrap these transports for you.

Not tied to one language — use these names when you search docs or design a system.