# Design a Resilient Chat System Design a chat system and trace data end to end through its components. Support direct and group conversations, message history, online delivery, offline catch-up, and basic membership changes. Concentrate on concrete component interactions, data flow, and failure cases rather than only naming services. During the discussion, be prepared to evaluate an alternative design that writes messages only to an in-memory broker before acknowledging them. Explain what is attractive about that proposal, where it fails, and how you would revise it. ### Clarifying Questions to Ask - What ordering and durability guarantees do users observe? - Are edits, deletes, attachments, presence, and read receipts required? - How many devices may one user have, and how do they resume independently? - Can group membership change while messages are in flight? - Which regional or storage failures are in scope? ### What a Strong Answer Covers - Explicit send, persist, publish, deliver, and acknowledge steps - Idempotency keys and stable message identifiers - Ordering scope and a cursor for gap-free history reads - Membership authorization at send and read boundaries - Online connection routing and offline replay - Durable handoff before success when durability is promised - Retries, duplicate delivery, backpressure, and poison-event handling - Component failure analysis, reconciliation, and observability - Honest trade-offs around availability, consistency, and user-visible lag ### Follow-up Questions - What happens if persistence succeeds but event publication fails? - How do you prevent a removed member from reading later messages? - How would you handle a hot group with many online recipients? - Which invariants would a background reconciler check?