Practice: five levels

Assignments

Five levels. Do them in order. Answers are in "Solutions" at the end, so try first.

Level 1: Think (no code)

A. Which transport? One line each.

1. A cricket app showing live scores on its match page.
2. A WhatsApp-style chat screen.
3. "Your order is out for delivery" when the phone is locked.
4. An admin panel checking whether a nightly export has finished.
5. A chatbot streaming its answer word by word in a web page.

B. True or false? Explain in one line.

1. SSE lets the browser send messages to the server over the same stream.
2. A WebSocket connection can be moved from one server to another without the client noticing.
3. A push notification is guaranteed to arrive.
4. With short polling, halving the interval halves the average delay and doubles the requests.
5. Every client should reconnect exactly 1 second after a disconnect.

Level 2: Calculate

1. 100,000 customers poll their order status every 5 seconds. How many requests per second? If an order has 5 updates in 20 minutes, what fraction of requests come back with nothing new?
2. What's the average delay of an update with polling every 5 s? Every 30 s?
3. 1 million open connections at an assumed 20 KB each. How much memory? At 100,000 connections per gateway, how many gateways, and how many would you run to survive one failing?
4. Heartbeats every 30 s on 1 million connections. How many pings per second? After 3 missed, how long until a dead connection is noticed?
5. 100,000 clients reconnect after a restart, spread evenly over 30 s with jitter. Roughly what's the peak per second, compared with no jitter?

Level 3: Build

In Python:

1. short_polling(event_times, interval, duration) returning requests, empty responses and average delay.
2. long_polling(event_times, timeout, duration) returning requests and empty responses.
3. sse_format(id, event, data) and sse_parse(stream).
4. A server-side OrderEvents with since(last_event_id), and a client that catches up on reconnect and ignores duplicates.
5. reconnect_peak(clients, base, jitter) showing the effect of jitter, and detect_dead(last_seen, now, interval, missed_allowed).

Level 4: Debug

Customers complain: "The app jumped straight from 'packed' to 'delivered'. I never saw the rider was assigned, so I missed the delivery call." The tracking client:

1. Find the bug. When exactly does it lose updates?
2. Fix it, so that reconnecting never loses or duplicates an update.

Level 5: Design

Design live order tracking for the grocery app: 100,000 concurrent trackers at peak, five status updates per order, the rider's position every 4 seconds while out for delivery, and a "delivered" alert even when the app is closed.

Deliver:

1. Which transport for each part (status, rider position, background alerts), and why.
2. The connection layer: gateways, how messages reach the right user, how many servers.
3. What happens when a phone loses signal for 2 minutes in the middle of a delivery.
4. How you deploy new gateway code without disconnecting everyone at once.
5. How the rider's 4-second position updates avoid overloading the system (hint: Chapter 18).