Design: Real-Time Chat Interview Questions
ADVANCED › System Design
Compare a persistent WebSocket connection against periodic short-polling for a chat app's foreground transport. Where does polling actually still make sense despite WebSocket being the obvious choice?
What a strong answer covers: A strong answer concedes WebSocket wins on latency and bidirectional push, but names real costs: maintaining a persistent connection burns battery and radio wake time, and some carrier or corporate proxy setups silently kill long-lived sockets. It should note polling can be fine for low-volume, check-occasionally chat, and that any WebSocket implementation still needs a poll-like reconnect-and-catch-up fetch as a fallback anyway, so the two aren't as opposed as they first appear.
A user is logged into the same chat account on their phone and a tablet at once. Walk me through what has to change in your design to keep both devices consistent for read state, history, and typing indicators.
What a strong answer covers: A strong answer recognizes that read state can no longer be assumed single-session; the server needs to track last-read-sequence per device or account and push a reconciliation event so an action on one device propagates to the other, meaning local Room storage becomes a per-device cache rather than the sole source of truth for social state. It should note typing indicators are usually fine to keep ephemeral and per-device since they aren't persisted. The trap is a design that assumed single-session read receipts and silently breaks with a second device.
Where would you actually put end-to-end encryption in this chat design, and what does it break that you'd already designed for, like search, notification previews, and multi-device sync?
What a strong answer covers: A strong answer explains that E2EE means the server can no longer read message content, so server-side search must move to on-device indexing per client, push notifications can only carry a wake signal rather than message text since FCM payloads would otherwise be plaintext, and multi-device sync becomes materially harder because each device needs its own key material and a session-establishment or re-encryption mechanism for history. The signal is recognizing E2EE constrains search, notifications, and sync simultaneously, so it has to be decided early rather than bolted on later.