# Design a Discord-Style Communication Platform Design a communication platform with organizations, channels, direct messages, and real-time text delivery. Users can belong to several organizations and channels. Cover APIs, data models, component interactions, storage, connection management, and important edge cases. Start with text messages and membership. Treat presence, typing indicators, attachments, search, moderation, and notifications as follow-up features whose consistency needs may differ from message history. ### Clarifying Questions to Ask - What is the ordering scope for messages? - How large can organizations and channels become? - Which permissions govern reading history and posting? - How long is history retained, and is search required immediately? - What does a sender acknowledgment guarantee? ### What a Strong Answer Covers - Organization, channel, membership, message, and device-session models - Idempotent message sends and per-channel sequence or cursor semantics - Durable storage before acknowledgment when durability is promised - Real-time gateways plus offline catch-up from authoritative history - Permission checks during membership changes and message reads - Partitioning and hot-channel mitigation - Separate treatment of durable messages and ephemeral presence or typing state - Failure cases: duplicate delivery, reconnect gaps, partial fan-out, stale permissions, and unavailable dependencies - Observability and reconciliation of durable state with asynchronous delivery ### Follow-up Questions - How would threads or replies change the data model? - How would you index search without delaying message delivery? - What happens when a user is removed while connected? - How would you support a channel with an unusually large audience?