Watch the 40-second version on YouTube
Every frontend system design interview has a moment where the candidate says "we will use WebSockets for real-time updates" and the interviewer nods. That nod is a trap. WebSockets are not an architecture. They are the first three minutes of the hard conversation.
Here is the production version of that question, and it has bitten me for real. A dashboard I worked on streamed ticks over a socket. Flawless in the demo. Then a user on hotel Wi-Fi dropped for four seconds, the socket reconnected, and the UI showed nothing wrong. Except the prices were stale. Not broken. Stale. The worst kind of wrong: confident and silent. The reconnect succeeded, the stream resumed, and every message from those four seconds vanished into the gap. Nobody noticed for a week. The fix was not a better socket library. It was everything around the socket.
That is what interviewers are really asking when they say "design real-time updates." They want the 3 AM cases.
Three things the demo never shows. First, reconnects are the actual product. The connect call is one line. The reconnect policy is the architecture: exponential backoff with jitter, or your whole fleet retries at the same instant like a tiny DDoS you wrote yourself. Plus a visible connection state in the UI, because presenting stale data as live is lying to your users.
Second, you need a position in the stream, not just a connection. Every message carries a sequence ID, and the client remembers the last one it processed. On reconnect, it resubscribes from that ID and replays the gap. No IDs, no resync. You are refreshing and praying.
Third, at-least-once delivery means duplicates, so every handler must be idempotent. Receiving the same message twice is correct behavior, not a bug. Apply it twice and get the same result, or your counters drift and nobody can say why.
The non-obvious angle: the interview answer is the incident review. Our stale-data post-mortem produced exactly those three action items: backoff with jitter, sequence IDs with gap replay, idempotent handlers. Interviewers are not testing whether you can recite socket docs. They are checking whether you have thought about what happens when the network lies, because it always does eventually.
Steal this for your next design doc or interview. The reconnect checklist, copy-paste friendly:
REAL-TIME CHECKLIST (the 3 AM contract)
1. Reconnect: exponential backoff + jitter, max delay cap.
2. UI shows connection state: never present stale data as live.
3. Every message has a sequence ID; client tracks the last processed.
4. Reconnect = resubscribe from last ID, replay the gap.
5. Handlers idempotent: same message twice, same result.
6. Heartbeats catch dead connections before users do.
I turned the full 60-question drill set into The Frontend System Design Interview Playbook ($19): https://bittalk.gumroad.com/l/frontend-interview-playbook
I broke this down in 40 seconds here: https://www.youtube.com/shorts/YYD2YfTcEK8
Top comments (1)
the stale prices story is the part that sticks. a broken socket gets fixed, a quietly stale one gets trusted.