38.5 What does the whole system look like?

Step 4: High-level design (10 minutes)

Figure: the final design. Gateways hold sockets; the chat service orders, stores and routes.

A message, step by step:

1. Asha's phone sends {chat c1, client_id a-002, ciphertext} over its WebSocket to gateway 3.
2. The chat service (for chat c1's shard) checks the client ID: if it's a retry, it returns the existing sequence number. Otherwise it assigns the next seq (2), writes the message to the message store, and acks Asha: one tick.
3. It looks up Ravi's devices in the session registry: phone on gateway 7, laptop offline.
4. It sends the message to gateway 7, which pushes it down Ravi's phone socket. The phone acks "delivered up to 2".
5. For the offline laptop: a push notification nudge (Chapter 21); when it reconnects, it syncs "after my cursor".
6. When all of Ravi's devices have it, Asha sees two grey ticks; when Ravi opens the chat, blue.

Interviewer pushback:

• "The chat service for c1 crashes after storing but before acking Asha." → Asha's app retries with the same client ID; the unique key finds the stored message and returns seq 2. No duplicate.
• "A gateway dies." → Its 100,000 clients reconnect (with jitter, Chapter 21) to other gateways, re-register, and sync from their cursors. Nothing is lost because messages are stored before delivery.

Memory code: "Store first, then deliver; ack with a sequence number."

---

Offer: "The interesting parts are the gateway tier, ordering and duplicates, ticks, offline delivery, groups and media. Which would you like?"