Real-time communication: polling, long polling, WebSockets, SSE

Step 1 Understand it

The problem it solves. Normal lets the ask but not the tell. Chat, notifications, live prices and multiplayer games need updates pushed to the user within a fraction of a second.

New words in this topic (tap one to see what it means)

Watch it happen

AnimationGetting the server to push: polling, long polling, WebSockets, SSE

Read the animation as text

Normal HTTP: the client asks, the server answers. For chat, live scores or notifications, the server needs a way to push.
Short polling: ask "anything new?" every few seconds. Simple — but most answers are "no", and each one costs a full request.
Long polling: ask, and the server holds the request open until there is news (or about 30 s pass). The client immediately asks again.
WebSocket: starts as an HTTP request with an Upgrade header; then the same connection stays open and either side can send at any time.
SSE (server-sent events): one HTTP request, and the server keeps sending events down it. One-way, simpler, and the browser reconnects by itself.

Picture it

flowchart LR
  A["User A"] <-->|"WebSocket"| G1["Gateway 1"]
  B["User B"] <-->|"WebSocket"| G2["Gateway 2"]
  G1 -->|"1 message for B"| CS["Chat service"]
  CS -->|"2 where is B connected?"| R[("Redis<br/>user → gateway")]
  CS -->|"3 forward"| G2

Each user keeps an open connection to one . To reach B, the chat service looks up B's gateway in and forwards the message there.

The idea

Normal HTTP is 'the client asks, the server answers'. Chat, live scores and notifications need the server to push. is simple but wasteful. Long polling holds a open until there's news. keep one connection open for messages in both directions. is a simpler one-way from server to client.

How it works, step by step

Short polling: the client asks 'anything new?' every few seconds. Simple, but most answers are 'no'.
Long polling: the client asks, and the server holds the request open until there's news (or a of about 30 seconds). The client immediately asks again.
WebSocket: starts as an HTTP request with an 'Upgrade' header. After that, the same connection stays open and either side can send a message at any time.
SSE: the client opens one HTTP request and the server keeps sending down it; the browser reconnects automatically if it drops.
At scale: users connect to many gateway servers. When user A messages user B, the system looks up B's gateway in a registry (such as Redis) and forwards the message there.

Analogy

Polling is a child asking 'are we there yet?' every minute. Long polling is asking once, and the driver only answers when you arrive. A WebSocket is an open phone line both people can talk on.

Where the analogy breaks

An open phone line costs nothing to keep open. Each WebSocket holds memory and a connection on a server, so millions of users need many connection servers, and a way to find which server each user is connected to.

Example

WhatsApp-style chat: each user keeps a connection to a gateway server, and a lookup store records which gateway holds each user, so a message can be routed to the right one.

Must-know points

Short polling: simple, but most are empty; high load, and a delay of up to one polling interval.
Long polling: fewer empty responses; works everywhere; one request per message.
WebSockets: two-way and low , but connections are , which makes and harder.
SSE: one-way, server to client, over normal HTTP; reconnects automatically; good for feeds and notifications.
Stateful connections need a 'who is connected where' registry, often in Redis.

Common mistakes

Choosing WebSockets for one-way updates, where SSE is simpler.
Forgetting that open connections make servers stateful: you need a connection registry and reconnect logic.
No plan for messages missed while a client was disconnected.

Step 2 Go further (free, optional)

Optional. The notes above are written to be enough on their own. These free resources give a second explanation and extra practice.

Watch

ByteByteGo: polling vs long polling vs websockets vs SSE

ByteByteGo · YouTube
Read

Hello Interview: design a chat system

hellointerview.com · free guides
Read

The WebSocket API

MDN Web Docs, free

Step 3 Practise

Try each exercise yourself first: on paper, out loud or in code. Then open the answer and compare it with yours.

ExplainSay it in plain words in under a minute, with no notes.

Explain polling, long polling, WebSockets and SSE with the 'are we there yet?' picture.

Show answer
• Short polling: the child asks "are we there yet?" every minute. Simple, but almost every answer is "no", and you can be up to a minute late hearing "yes".
• Long polling: the child asks once, and the driver stays quiet until they arrive (or for at most 30 seconds), then answers. The child asks again straight away. Fewer wasted questions, and the answer comes the moment it is true.
• WebSocket: an open phone line. Once the call is connected, either person can speak at any time, in both directions.
• SSE (server-sent events): the driver's announcements over the car speaker. The driver talks whenever there is news; the child only listens. One-way, and it reconnects by itself if it drops.

DrawSketch the diagram (or class diagram) from memory.

Draw how a message travels from user A to user B when they are connected to different WebSocket servers.

Show answer

Gateways hold the open connections but don't know where other users are; the registry does. The message is also saved before it is forwarded, so B can fetch it later if B was offline or the forward failed.

text

User A ═══ WebSocket ═══ Gateway 1
                            │ 1. "message for B"
                            ▼
                       Chat service
                         │   │ 2. save the message
                         │   └──────────► Database
                         │ 3. where is B?
                         ├──────────────► Redis
                         │ ◄── "Gateway 2" ┘
                         │ 4. forward
                         ▼
User B ═══ WebSocket ═══ Gateway 2

ApplyUse it in a real design question and say exactly where it fits.

Choose a method for: a stock price ticker, a chat app, a nightly report, and a delivery-tracking map. Justify each.

Show answer
• Stock price ticker: SSE. Updates only flow from server to client, many times a second, and SSE is a simple stream over normal HTTP that reconnects by itself. (If the same screen also places trades, a WebSocket can carry both.)
• Chat app: WebSockets. Messages go both ways, typing indicators and read receipts need low latency, and one open connection is much cheaper than polling.
• Nightly report: none of them. It is ready once a day, so a normal request is enough: email a link or send a notification when it is done, or let the page poll the job status every 30 seconds while someone waits.
• Delivery-tracking map: SSE (or a WebSocket). The courier's position arrives every few seconds and only flows to the customer. Polling every 5 to 10 seconds also works at small scale, and is simpler to build.
The rule: two-way and fast means WebSockets; one-way and frequent means SSE; rare updates mean ordinary requests or polling.
Trade-offsSay what it costs, when not to use it, and the alternative.

What does it cost to hold 10 million open WebSocket connections, and how would you spread them across servers?
Show answer
The costs of 10 million open connections:
• Memory: each connection holds buffers and some state, say about 20 , so roughly 200 GB of memory in total.
• Servers: a well-tuned server holds about 100,000 to 1,000,000 connections. At 100,000 each, that is 100 gateway servers, plus spare capacity for failures.
• : a ping every 30 seconds per connection is about 330,000 small messages a second, just to keep connections alive.
• File handles, work, and load balancers that must support long-lived connections.
Spreading them:
• Put a layer-4 load balancer (or ) in front of a fleet of gateway servers, sending new connections to the least-loaded one.
• Keep a registry (Redis) of user → gateway, updated on connect and disconnect, so any service can route a message to the right gateway.
• Plan for failure: when a gateway dies, its 100,000 users reconnect at once. Clients must back off with random , so they don't the other servers.
• On deploys, drain servers slowly (stop new connections, then close old ones gradually), rather than dropping everyone at once.
python
```
connections = 10_000_000
memory_gb = connections * 20e3 / 1e9          # about 20 KB each
servers = connections / 100_000               # 100k per server
pings_per_s = connections / 30                # one ping every 30 s
print(memory_gb, servers, round(pings_per_s))
# 200.0 100.0 333333
```

Step 4 Interview-ready, then prove it

Your interview answer

About 20 to 40 seconds, said out loud. Practise it until it sounds like you, not like notes.

For chat I'd use WebSockets, because messages flow both ways with low latency. Users connect to a fleet of gateway servers, and Redis maps each user to their gateway so a message can be pushed to the right connection. For one-way updates like live scores, SSE is simpler.

Follow-up questions

What happens when a WebSocket server crashes?

Clients reconnect (with ) to another server, re-register where they are, and fetch any missed messages using the last message ID they saw.

Why not just poll every second?

With millions of users, that's millions of mostly empty requests every second: huge cost for little benefit.

Tick each check when you can do it without notes

A topic is finished when you pass all four checks, not when you finish a video. Be strict: if you needed your notes, it is not ticked yet.

ExplainExplain Say it in plain words in under a minute, with no notes.
DrawDraw Sketch the diagram (or class diagram) from memory.
ApplyApply Use it in a real design question and say exactly where it fits.
Trade-offsTrade-offs Say what it costs, when not to use it, and the alternative.

0 of 4 checks ticked.

Saved in this browser. Back it up or move it to another device.