Chat, notifications, live dashboards, streaming AI responses — more and more of an app needs to update without a refresh. “Real-time” sounds like one feature, but it's a spectrum with very different techniques. This lesson frames the problem before the next one dives into solutions.
Cold open
Real-time is everywhere now
Every modern product streams something the instant it changes — and the AI wave made it the default. Tap through a few you use daily:
◎
ChatGPT
streams via SSE
✶
Claude
streams via SSE
✦
Gemini
streams via SSE
➤
Cursor
live collaboration
Notifications · presence dots · live counters · collaborative cursors · streaming AI — every one rides on the same three techniques.
Frame it first
It's a requirements question
In an interview, “design a chat” or “design a stock ticker” is not a prompt to blurt “WebSockets!” The point is to show you map requirements and constraints to a technique — not that you memorized one tool:
Interviewer
“Design a stock application. How do you update prices in real-time?”
Mid-level dev
✕ WebSockets!
Jumps straight to the answer they've heard most.
Senior dev
✓ Let's check the requirements first.
Reasons about the problem before naming a tool.
The real test: not whether you've heard of WebSockets — whether you can resist the urge to jump to them.
And there's no single right tool. Two products with nearly the same feature can pick opposite techniques:
LinkedIn
Uses SSE for instant messaging
Chat is supposedly the canonical WebSocket use case — so why didn't they use WebSockets?
Stack Overflow
Uses WebSockets for the feed
But feed updates are one-directional, server-to-client only. Why not SSE or polling?
Same problem shape → different answer, depending on infrastructure, scale, and constraints.
Note
LinkedIn messages use Server-Sent Events; Stack Overflow's live counts use WebSockets; a slow dashboard might just poll. Each fit the tool to their infra, scale, and constraints — exactly the reasoning the five questions below tease out.
Clarify
Five questions to ask first
Before choosing anything, pin down the problem. Tap each:
Not a boolean
Real-time is a spectrum
“Real-time” isn't true/false — it's how much staleness your users can tolerate before they notice. Drag the acceptable delay and watch the fitting family change:
Acceptable staleness window
instantminutes
Near real-time~1–5s
Chat · notifications
Typical fit: SSE / long polling
The staleness window
Ask “how stale can this data be before it's a problem?” An email arriving 2s late is invisible; a trading price 2s late is a bug. That window — not a buzzword — picks your technique.
The root problem
Why HTTP makes this hard
Plain HTTP is one-sided: the client opens a request, the server responds, the connection closes. The server is the source of truth — but it has no way to start a conversation when new data appears:
🖥
Client
🗄
Server
GET /messages
The client always starts; the server only answers, then the connection closes. The server can't push first — every real-time technique is a workaround for this.
Every real-time technique is a workaround for this single limitation: how do we let the server's fresh data reach the client when only the client can knock on the door?
The solution space
Three families of workaround
All techniques fall into three families. Tap (or autoplay) to watch how each shuttles data:
🖥
Client
🗄
Server
GET?
data
Client pull · short / long polling
The client keeps asking “anything new?” The server only ever answers a request — it can't start the conversation.
Client pull (short & long polling) keeps asking. Server push (Server-Sent Events) holds one connection open and streams down it. Full-duplex (WebSockets) keeps a two-way channel where either side can speak. The next lesson starts with the simplest family — client pull.
Practice
Check your understanding
Q1Multiple choice
An interviewer says “design a chat app.” The best first move is to…
Q2Multiple choice
Why can't plain HTTP deliver real-time updates on its own?
Q3Sort each scenario
Which family does each describe?
The client repeatedly asks “anything new?”
One open connection streams events server→client only
Either side can send at any time over one connection
Try it yourself
Design challenge
For three products, place each on the spectrum and justify a family:
A collaborative document (multiple cursors).
A notifications bell.
A “new posts available” banner on a feed.
Name the staleness window for each, then the family you'd reach for and why.
Key takeaways
→Real-time is a requirements question — clarify before choosing a tool.
→Ask about staleness, direction, frequency, infrastructure, and scale.
→It's a spectrum (hard → near → soft → eventual) measured by the staleness window.
→Plain HTTP can't push — the client initiates and the connection closes; every technique works around that.
→Three families: client pull, server push (SSE), and full-duplex (WebSockets).