## Design a One-to-One Chat System The source identifies a one-to-one chat system as the design topic without specifying scale or product behavior. For this practice version, design durable direct messaging between two accounts, including multi-device delivery, offline recovery, conversation history, and optional delivery and read state. Group chat, presence, attachments, and end-to-end encryption must be clarified rather than assumed. ### Part 1 — Define the Messaging Contract Specify conversation, participant, message, client operation, device, and receipt records plus APIs for opening a conversation, sending messages, reading history, and acknowledging progress. #### What This Part Should Cover - One stable conversation identity for the authorized pair under the chosen product rule. - Caller-scoped idempotency for sends and immutable message identity. - Explicit message ordering, edit, deletion, retention, and pagination semantics. - Authorization checks that do not trust participant IDs supplied by a client. ```hint Separate retry identity from message order A client operation ID prevents a duplicate send, while a server-assigned position determines where the accepted message belongs. ``` ### Part 2 — Deliver Online and Recover Offline Design the path from an accepted write to connected recipient devices, push notifications where applicable, reconnect synchronization, and delivery or read acknowledgements. #### What This Part Should Cover - Durable acceptance before an acknowledgement claims the message was sent. - At-least-once transport with client deduplication by message identity. - Per-device synchronization cursors and gap recovery from durable history. - A distinction among accepted, delivered to a device, and read by the account. ```hint Reconnect from a durable position An open socket is a delivery optimization, not the source of truth for messages missed while a device was offline. ``` ### Part 3 — Partition and Handle Failure Choose authoritative storage and partitioning, then address concurrent sends, service retries, connection churn, slow consumers, and a user signed in on several devices. #### What This Part Should Cover - One ordering owner or conditional sequence allocation per conversation. - A transactional outbox or equivalent durable handoff from storage to delivery. - Backpressure and bounded connection or delivery queues. - Recovery from an accepted write whose client acknowledgement was lost. ```hint Keep one ordering boundary Independent writers cannot promise one conversation order unless they coordinate through shared state or one owner. ``` ### Part 4 — Protect and Operate the Service Cover participant privacy, blocking and abuse controls, encryption boundaries, retention or deletion, reconciliation, and observable service health. #### What This Part Should Cover - Authentication and membership checks on send, history, and receipt operations. - Encryption in transit and at rest, with end-to-end encryption treated as a separate product contract. - Repair of delivery events, device cursors, and conversation indexes from authoritative messages. - Metrics for acceptance, duplicate retries, delivery delay, reconnect gaps, queue pressure, and authorization failures. ```hint Measure each promise separately Write durability, online delivery, offline synchronization, and read state fail at different boundaries and should not share one success metric. ``` ### What a Strong Answer Covers - Defines idempotent send, durable acceptance, ordering, and pagination precisely. - Treats sockets and notifications as delivery paths over authoritative message history. - Supports offline and multi-device clients without claiming exactly-once transport. - Includes authorization, bounded queues, repair, retention, and clear state semantics. ### Follow-up Questions 1. How would both participants sending concurrently receive one deterministic conversation order? 2. What should the sender see when the write committed but its response was lost? 3. How would a newly linked device obtain history without exposing another account's conversation? 4. Which design choices change if end-to-end encryption becomes mandatory?