Design a One-to-One Chat Service

# Design a One-to-One Chat Service Design a messaging service for private conversations between two users. Cover message sending, retrieval, ordering, online and offline delivery, read state, retries, and failure recovery. Explain what guarantees the service provides when clients reconnect or submit the same request more than once. ### Constraints & Assumptions - A conversation has exactly two participants. - Text messages are retained; large media storage is outside the core path. - Users may have several devices and may be offline for long periods. - Global ordering across unrelated conversations is unnecessary. - The service must prevent nonparticipants from reading a conversation. ### Clarifying Questions to Ask - Is strict ordering required within a conversation or only per sender? - Must delivery receipts and read receipts be supported? - What retention and deletion rules apply? - What peak send rate and reconnect fan-out should be expected? ### Part 1 - API and data model Define conversation, message, participant, cursor, and receipt records plus send and history APIs. #### What This Part Should Cover - Client-generated idempotency keys - Conversation-scoped ordering IDs - Authorization at read and write boundaries - Cursor-based history retrieval ### Part 2 - Delivery and consistency Explain the durable write path, live delivery path, offline recovery, multi-device synchronization, and duplicate handling. #### What This Part Should Cover - Persist before acknowledging accepted messages - At-least-once delivery with client deduplication - Per-conversation order and reconnect cursors - Receipt semantics separated from message durability ### Part 3 - Scale and failures Discuss partitioning, hot conversations, WebSocket gateways, backpressure, regional failure, and observability. #### What This Part Should Cover - Stable partition key and bounded fan-out - Stateless gateways with resumable sessions - Queue lag and slow-client protection - Reconciliation after partial failure ```hint Give each accepted message a stable identity A server message ID plus a client idempotency key makes retries safe and lets every device deduplicate replayed delivery. ``` ### What a Strong Answer Covers - A precise durable-send and ordered-history contract - Safe retries, reconnect recovery, and multi-device behavior - Participant authorization and privacy boundaries - Partitioning, delivery fan-out, backpressure, and failure observability ### Follow-up Questions 1. How would you preserve conversation order if two participants send at the same time? 2. What happens when a WebSocket gateway fails after receiving but before forwarding a message? 3. How would end-to-end encryption alter storage, search, and abuse controls?