Interview questions

Interview questions (with the counter-questions you'll get)

Q1. Compare short polling, long polling, SSE and WebSockets.

They're testing: the core comparison.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Short polling asks on a timer: simple, but wasteful and delayed by about half the interval. Long polling holds each request until there's news or a timeout: near-instant over plain HTTP, but each held request occupies the server. SSE streams events server to client over one HTTP response, with automatic reconnect and resume. WebSockets upgrade to a two-way channel: lowest overhead and bidirectional, but stateful and more work to operate.
3
4**Counter-questions:**
5- *"Which would you pick for live sports scores?"* → SSE: one-way, HTTP-friendly, resumes automatically. WebSockets only if the client sends a lot too.
6
7**Trap:** choosing WebSockets for everything.

Q2. How do you scale WebSockets to millions of users?

They're testing: stateful connection design.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Dedicated gateway servers, event-driven, holding many idle connections each, with OS limits raised. A pub/sub backplane or a connection registry routes each message to the gateway holding the user. Load balancers configured for long-lived connections and balanced by connection count. Business logic in separate services so it can deploy independently.
3
4**Counter-questions:**
5- *"A gateway dies. What happens?"* → Its clients reconnect, with jitter, to other gateways and catch up from their last event ID.
6
7**Trap:** forgetting the "which server holds this user?" problem.

Q3. How do you make sure a client doesn't miss messages after reconnecting?

They're testing: reliability on unreliable networks.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Give every event an increasing ID per stream; the client tracks the last ID it processed and sends it on reconnect; the server replays later events from a buffer or the database. The client de-duplicates by ID. For long gaps, re-fetch the full current state instead.
3
4**Counter-questions:**
5- *"How long do you keep the buffer?"* → Long enough for typical disconnections (minutes); beyond that, the client re-fetches state.
6
7**Trap:** assuming a reconnected socket picks up where it left off.

Q4. What are heartbeats for?

They're testing: operational detail.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** To detect connections that died silently, so the server can free resources and the client can reconnect; and to keep proxies and load balancers from closing idle connections. Typically a ping every 15 to 60 seconds, with a connection declared dead after a few missed.
3
4**Counter-questions:**
5- *"Cost at scale?"* → A million connections at 30 s is about 33,000 small pings a second; cheap, but it adds up, and mobile clients pay in battery.
6
7**Trap:** relying on TCP to report dead connections promptly.

Q5. What's a thundering herd on reconnect, and how do you prevent it?

They're testing: failure thinking.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** When a server restarts, all its clients reconnect at once, overloading the new server and possibly crashing it again. Prevent it with exponential backoff plus random jitter, server-side connection rate limits, and graceful draining during deploys so clients leave in a spread-out way.
3
4**Counter-questions:**
5- *"Where else does this happen?"* → Cache expiry (Chapter 13's stampede), retries after an outage (Chapter 29).
6
7**Trap:** fixed retry intervals.

Q6. How do push notifications work?

They're testing: mobile realities.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** The app registers with APNs or FCM and gets a device token, which it sends to your server. To notify, your server sends the token and a small payload (up to 4 KB) to APNs or FCM, which delivers it over the phone's single persistent connection to the platform. Delivery isn't guaranteed or ordered, so treat it as a nudge and let the app fetch the real state.
3
4**Counter-questions:**
5- *"Device tokens go stale. What do you do?"* → Update them on every app start, and remove tokens the push service reports as invalid.
6
7**Trap:** putting critical data only in the push payload.

Q7. Design the "typing..." indicator in a chat app.

They're testing: applying WebSockets sensibly.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Over the existing WebSocket, the client sends "typing" at most every few seconds while typing, and the server forwards it to the other participants' gateways via pub/sub. Receivers show the indicator and hide it after a short timeout if no new event arrives. Don't store it or retry it; it's disposable.
3
4**Counter-questions:**
5- *"Group of 500?"* → Throttle harder, show "several people are typing", or turn it off for large groups.
6
7**Trap:** sending a message on every keystroke and storing it.

Q8. Why might you choose SSE over WebSockets?

They're testing: judgement, not fashion.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** When only the server sends updates, SSE is simpler: plain HTTP, works with existing auth, load balancers, HTTP/2 and proxies, and has built-in reconnect and resume with Last-Event-ID. Fewer moving parts to operate.
3
4**Counter-questions:**
5- *"Downsides?"* → One-way and text only; over HTTP/1.1, browsers limit connections per domain to about 6, shared across tabs.
6
7**Trap:** not knowing SSE exists.

Q9. How do you authenticate a WebSocket connection?

They're testing: security on stateful connections.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Authenticate during the HTTP handshake, with a cookie or a short-lived token, and reject the upgrade if invalid. Since the connection lives for hours, re-check periodically or when the token expires, and close the connection when a user logs out or loses access. Authorise each subscription ("can this user watch order 881?").
3
4**Counter-questions:**
5- *"Why not put a long-lived token in the URL?"* → URLs get logged; use short-lived tokens or cookies.
6
7**Trap:** authenticating once and trusting the connection forever.

Q10. How would you deploy new code to WebSocket servers without disconnecting all users at once?

They're testing: operating stateful services.

Think about your answer first, then open it.

reveal

1Show the strong answer, counter-questions and trap
2**Strong answer:** Roll gateways one at a time. Each one stops accepting new connections, tells connected clients to reconnect (with jitter) and waits for most to leave before shutting down. Keep gateways thin, so most code changes deploy to stateless services behind them without touching connections.
3
4**Counter-questions:**
5- *"What does the client need to support this?"* → Handling a "please reconnect" message, jittered reconnects, and resuming from the last event ID.
6
7**Trap:** a normal rolling restart that drops thousands of connections in one go.
8
9---
10
11## Practice coverage
12
13Every section in this chapter is tested at least once.
14
15| Section | Tested by |
16|---|---|
17| 21.1 The problem | Level 1A, Q1 |
18| 21.2.1 Short polling | Level 1A.4, Level 1B.4, Level 2.1, Level 2.2, Level 3.1, Q1 |
19| 21.2.2 Long polling | Level 3.2, Q1 |
20| 21.2.3 SSE | Level 1A.1, Level 1A.5, Level 1B.1, Level 3.3, Q8 |
21| 21.2.4 WebSockets | Level 1A.2, Level 1B.2, Q7, Q9 |
22| 21.2.5 Mobile push | Level 1A.3, Level 1B.3, Level 5.1, Q6 |
23| 21.3 Millions of connections | Level 2.3, Level 5.2, Q2, Q10 |
24| 21.4 Heartbeats and reconnects | Level 1B.5, Level 2.4, Level 2.5, Level 3.4, Level 3.5, Level 4, Level 5.3, Q3, Q4, Q5 |
25| 21.5 How to choose | Level 1A, Level 5.1, Q1, Q8 |
26
27---

21. Polling vs WebSockets vs Push