Day 3 Review — TCP/UDP, WebSockets, Long Polling, SSE — 2026-07-22

Score: 8.15 / 9 (90.6%) Verdict: Breakthrough day. +7.6% jump from Day 2. This is the depth interviewers reward — clean structure, own words, real-world components. One meaningful mistake (Q6.1 trading UI) that's a genuine learning moment.

Question-by-question

Q1 (MCQ) — TCP guarantees ✅ 1.0 / 1.0

B — Correct. TCP: reliable, in-order, ACK-driven. UDP: none of that.

Q2 (MCQ) — When to pick UDP ✅ 1.0 / 1.0

C (live video-call frames) — Correct. Classic stale > missing case.

Q3 (MCQ) — Live sports scoreboard ✅ 1.0 / 1.0

C (SSE) — Correct. One-way (S→C), HTTP-native, auto-reconnect, cheaper than WebSockets when the client doesn't talk back.

Q4 (T/F) — WebSockets are bi-directional ✅ 0.9 / 1.0

True — Correct answer.

Small technical nit in your reasoning: you said "once it's done then the client and server can share information through TCP connections." Small imprecision — the connection was always on TCP. What the HTTP 101 Switching Protocols handshake does is tell the connection to change its framing protocol from HTTP → WebSocket frames. Same TCP socket the whole time.

Cleaner phrasing:

True. After the HTTP Upgrade: websocket handshake, the same TCP connection carries WebSocket frames in both directions with minimal (~2-14 byte) overhead. Full duplex — both sides can send at any time.

Q5 (T/F) — TCP head-of-line blocking ✅ 0.9 / 1.0

True — Correct with the right concept. Just tighten the wording:

True. Because TCP guarantees in-order delivery, the receiving kernel buffers already-arrived later packets and doesn't hand them to the application until the missing earlier packet is retransmitted and received. On a lossy network, one lost packet stalls the entire stream. This is the reason HTTP/3 abandoned TCP for QUIC/UDP.

Q6 (Short) — Map 5 systems to push mechanisms ⚠️ 4.0 / 5.0

Four out of five right. One meaningful miss on the first one:

#1 — Why SSE is wrong here: you correctly saw the real-time need, but SSE is one-way (server → client only). The prompt said the user "streams live prices AND lets the user place orders in real-time." Order placement is client → server, so SSE alone can't do it.

Two acceptable answers: - Best: WebSockets — full-duplex handles both prices (S→C) and orders (C→S) on one connection with lowest latency. - Acceptable hybrid: SSE for prices + normal HTTPS POST for orders — works, but you added a second mechanism.

The mental habit to build:

Every time you see "the user does X and the server pushes Y," ask: is it bi-directional? If yes → WebSockets. If no → SSE.

Q7 (Short) — SSE vs WebSockets ✅ 0.85 / 1.0

Correct core: SSE = one-way, WebSockets = duplex. Your rule of thumb (WebSockets when both talk back and forth; SSE when server-dominant) is exactly right.

One paragraph to memorize — the framing FAANG interviewers love:

SSE is HTTP-native (works with any HTTP infra), auto-reconnecting via the browser's EventSource API, and server→client only. Best for feeds, notifications, dashboards, LLM streaming — anywhere the client doesn't talk back. WebSockets upgrade an HTTP connection into a full-duplex frame stream (~2–14 bytes overhead per message), needed for chat, gaming, live collaboration, trading — anywhere it's a conversation.

Q8 (Scenario) — 10M-user chat system ✅ 0.8 / 1.0

Solid architecture that covers all four sub-parts: - ✅ WebSockets for web/desktop - ✅ APNs/FCM for mobile background - ✅ Sticky sessions or WebSocket gateway for LB - ✅ Redis/Kafka pub-sub for cross-server messaging - ✅ Keepalive pings for mobile flakiness

Two things to sharpen:

1. Ping interval "10–20 s" is too aggressive. Every ping is a network round-trip that (on mobile) wakes the radio, drains battery, and costs bandwidth. Industry standard: 30–60 s, sometimes up to 120 s. WhatsApp is known to use ~4 min intervals on mobile with careful tuning. Aggressive pinging is a common junior-engineer mistake.

2. Missing: capacity math. For a 10M-user system, an interviewer expects back-of-envelope numbers. Something like:

"A well-tuned WebSocket gateway can handle ~100k concurrent connections per host (with nofile raised, epoll, low-memory-per-conn framework). 10M / 100k = ~100 gateway hosts minimum. Add ~30% headroom for burst = ~130 hosts. Each fronted by an LB layer. Downstream: Redis/Kafka cluster sized for peak message fan-out."

Always tie back to Day 2's back-of-envelope discipline — even for architecture questions.

Bonus if you had said: - Message store: Cassandra or DynamoDB — write-heavy, timeseries by user/chat ID, easy horizontal scale. - Delivery guarantees: at-least-once with client-side dedup (Kafka semantics), or exactly-once if you use idempotency keys per message.

Q9 (Mini design) — WebSocket deploy incident ✅ 0.9 / 1.0

Excellent structure and clean prose. Root cause diagnosis nailed: - ✅ Thundering herd reconnect storm - ✅ CPU saturation from concurrent handshakes - ✅ DB contention from state re-hydration

Mitigations — all four are valid and correctly-scoped: - ✅ Exponential backoff + jitter - ✅ Rate limiting at gateway/LB - ✅ Connection draining on deploy - ✅ Redis cache in front of downstream DBs

Two bonus mitigations a senior candidate would add:

• Staggered rolling restarts (5% at a time instead of 25–50%) → smooths the reconnect rate across time; the herd never all sees the same wave.
• Session tokens / signed cookies so re-hydration doesn't need a DB read at all — the client's own token carries enough state to resume the session (short-lived, signed, re-verifiable). Combined with the Redis cache, DB gets 0 traffic on reconnect.

Also: client-side connection health monitoring with graceful upgrade windows — if the client sees the server hint at "planned restart in 30 s," it can pre-emptively reconnect at a random time in that window rather than reacting to a hard disconnect.

Score progression

You've crossed the 90% threshold. Two more days at this level and you're operating at Mid → Senior FAANG-candidate depth for these foundations.

Top 3 lessons from today

1. Bi-directional check before picking SSE. SSE is server → client only. If the client also talks back in real-time, you either need WebSockets, or a hybrid (SSE + POST). This is the exact trap in Q6.1.
2. Ping interval trade-off. On mobile, longer = less battery + less bandwidth, but risks the network middleboxes killing the connection silently. Sweet spot is 30–60 s (sometimes longer with careful negotiation).
3. Always include capacity numbers in architecture answers. "10M / 100k per host = 100 hosts" earns FAANG credit even if the number is approximate. It shows you can size a system, not just draw boxes.

Weak-area queue update