Design a scalable **one-on-one (1:1) chat service**. The service lets registered users exchange private text messages in real time across web and mobile clients. A single user may be signed in from multiple devices simultaneously, and every device should stay consistent. The system must handle online delivery, persistent message history, offline recipients, read receipts, and basic reliability guarantees. Walk through your design end to end: clarify the requirements, sketch the public APIs, define the data model, lay out the high-level architecture, explain the real-time delivery mechanism, justify your storage choices, describe how the system scales, and analyze how it behaves under failure. Call out the key trade-offs behind each decision. ```hint Where to start Anchor everything in **functional vs. non-functional requirements**, then do a back-of-envelope estimate (writes/sec, storage/day, peak concurrent connections). Let those numbers drive the rest of the discussion — they're what tells you whether a single store is enough, whether the connection-handling tier needs its own scaling story, and how aggressively delivery and persistence need to be decoupled. ``` ```hint Two jobs, possibly two paths Notice that "store the message durably" and "get it onto the recipient's screen right now" are different jobs with different failure and scaling properties. Decide whether one component does both or whether you split them, and be ready to defend it. Also consider where long-lived client connections actually live: ordinary request/response API servers don't naturally hold them, so think about what tier owns connections and how the system knows which one a given user is attached to. ``` ```hint Ordering, retries, and catching up Three correctness questions you'll be pushed on: (1) **Ordering** — what determines the order of messages in a conversation? Weigh the candidate schemes (e.g. a per-conversation counter vs. server timestamps) and name the failure each one risks. (2) **Retries** — a client resends because it never saw an ack; how do you keep that from creating a duplicate, and how does the recipient avoid showing the same message twice? (3) **Offline catch-up** — when a recipient reconnects after missing messages, how do they learn exactly what they missed without you maintaining unbounded per-user state? ``` ```hint The reliability gap to probe Trace what happens between "the message is durably stored" and "the fanout/notification for it has been published." If those are two independent steps, picture a crash landing in the gap, in either order, and ask what the user sees — a lost real-time push, or a notification pointing at a message that isn't yet queryable. The interviewer wants you to surface this window and propose how to close it, not to assume it away. ``` ### Clarifying Questions to Ask - **Scope of messaging:** Is this strictly 1:1 text chat, or should the design leave room for group chat, media attachments, or end-to-end encryption later? - **Scale and traffic shape:** Roughly how many registered users, daily active users, and peak concurrent connections should we target? What is the average message rate per user? - **Latency and consistency SLAs:** What end-to-end delivery latency is acceptable for online users? Must message ordering be strict within a conversation? - **Delivery guarantees:** Is at-least-once delivery acceptable (with client-side dedup), or is exactly-once a hard requirement? How long must message history be retained? - **Multi-device behavior:** When a user reads a message on one device, must read state and history sync across all their other devices? - **Offline expectations:** When a recipient is offline, do we push a mobile notification, queue the message, or rely on sync-on-reconnect — and how far back should reconnect sync go? ### Constraints & Assumptions - State your own capacity numbers explicitly (registered users, DAU, peak concurrent connections, messages/user/day, average payload size) and derive write throughput and daily storage from them. - Online delivery should feel real time (low hundreds of milliseconds end to end). Sending and reading must degrade gracefully during partial outages. - Acknowledged messages must be durable — once the server confirms a send, the message is not lost. - Assume a single logical product surface (web + iOS + Android) backed by one backend; cross-region replication can be mentioned but is not the core focus. ### What a Strong Answer Covers ```premium-lock What a Strong Answer Covers ``` ### Follow-up Questions - How does the design change if you extend it to **group chat** with large groups — what becomes the new bottleneck, and what breaks first? - A single conversation grows to millions of messages and one user is extremely active. How do you avoid a **hot partition** in the message store? - At **10x the connection count**, how do you scale the WebSocket/gateway tier, route events to the owning gateway, and detect and recover dead connections? - How do you guarantee that read receipts and delivery receipts stay consistent across a user's **multiple devices**, and what consistency guarantee do you actually offer there?