PM system design: message delivery, storage and scaling for a messaging service

Design the system behind a messaging platform. Explain how a message gets from sender to recipient, where conversations are stored, and how the design holds up as usage grows. ```hint Set the guarantees first Before drawing components, decide what the platform promises about each message: whether it can be lost, whether order is preserved, and what happens when the recipient is offline. Those promises shape most of the design. ``` ### Clarifying Questions - Is this a consumer chat app between people, a workplace product organized around channels, or a message bus that internal services use to talk to each other? - Are group conversations, attachments and end-to-end encryption in scope, or should I start with text between two people? - What scale should I plan for, in daily active users and messages per user? - When they conflict, which matters most: delivery latency, guaranteed and ordered delivery, or cost? ### What a Strong Answer Covers - Scoped functional and non-functional requirements, with a rough load estimate - The path a message takes from send to delivery, including recipients who are offline or signed in on several devices - A data model and storage choice for conversations and messages, justified by the access pattern - Scaling and failure handling: connections, partitioning, retries and duplicate messages - The product trade-offs the design forces, such as delivery guarantees, privacy, abuse and cost ### Follow-up Questions - How would you add read receipts and typing indicators without overloading the system? - What changes if every conversation must be end-to-end encrypted? - How would you handle a very large group or channel, where one message has to reach a huge number of members?