Loading…
Real-time system questions cover WebSockets, presence, conflict resolution and the connection-state problem behind chat, collaboration and live features.
Real-time systems maintain a persistent connection so the server can push rather than wait to be polled. That single change — from stateless requests to long-lived connections — is what makes these designs distinctive: connections are state, state has to live somewhere, and load balancing something stateful is harder than load balancing something stateless.
Interviewers probe connection state first: which server holds a given user's socket, what happens when that server restarts, and how a message reaches a user connected elsewhere. Presence is a favourite follow-up because it is deceptively expensive at scale. For collaborative editing, the expected discussion is conflict resolution and why last-write-wins is inadequate when two people edit the same region.
9 system design · 1 cloud architecture · 0/0/10 easy/medium/hard
WebSockets when updates are frequent and latency matters, since the connection stays open. Polling remains reasonable when updates are rare — it is stateless, trivially load balanced, and avoids the whole connection-affinity problem.
Because it is high-frequency, short-lived state that fans out to everyone watching. Naive designs write every status change to a database; workable ones keep it in memory with expiry and accept approximate accuracy.