Design a Messaging App with Group Sends, Chat History and Chat Deletion

Design a messaging app that supports the following: 1. A user can send a new message to one recipient or to several recipients. 2. A user can retrieve the chat history. 3. A user can delete a chat. The app stores all messages internally, on its own servers. These three requirements are the whole specification reported for this software engineering system design round, so settle the scale and the exact meaning of each operation with the interviewer before designing. ```hint What is a chat? Decide which entity a message belongs to when it goes to several recipients, so that retrieving a chat's history is one ordered read rather than a merge of many sources. ``` ```hint Delete for whom? Decide whether deleting a chat removes it for the user who deletes it or for every participant, and what that means for messages stored once but seen by several people. ``` ### Constraints and Clarifications - Every message is stored on the server; the app is the system of record for history. - Not given: the number of users, message volume, the largest number of recipients, media support, real-time delivery requirements, encryption, and how long history is kept. Ask, or state your assumptions. ### Clarifying Questions - Does sending to several recipients create a group chat with a stable membership, or a one-off broadcast that lands in each recipient's one-to-one chat? - Does deleting a chat remove it only from the deleting user's view, or for every participant? Must the stored messages be physically erased, and by when? - Must online recipients receive messages in real time, or is fetching history enough? Are read receipts needed? - Text only, or also images and files? - How many users and messages a day, and how large can a group be? - How far back must history go, and how is it paged? ### What a Strong Answer Covers - Settles the meaning of multi-recipient sends and of chat deletion before designing - A data model of conversations, members and messages with a per-conversation ordering key, partitioned for the history read - A send path with idempotent client retries, a durable write before acknowledgment, and delivery to recipients - History retrieval with cursor-based pagination that respects each user's deletion point - Deletion implemented to the agreed semantics, including physical cleanup once nobody can see a message - Scaling, very active groups, failure handling and observability ### Follow-up Questions - A user deletes a chat and then receives a new message in it. What do they see? - One group has thousands of members and is very active. What changes in delivery and storage? - A client retries a send after a timeout. How do you prevent a duplicate message? - Regulation requires deleted messages to be erased from storage within a fixed period. How do you guarantee it, including in backups?