## Design Chat APIs, Storage, and Core Message Flows Design the API and database model for a chat service. Cover direct and group conversations, sending messages, reading message history, membership changes, and the basic flow from an accepted send to recipient visibility. State which delivery and ordering guarantees the product actually needs. ### Constraints & Assumptions - A conversation has stable membership and message identities; group membership changes are versioned. - Clients may retry a send after a timeout, so acceptance must be idempotent. - Messages need a deterministic order within a conversation, but no global order across conversations is required. - Deletion, edits, attachments, read receipts, and offline push delivery are optional until clarified. - Required message volume, group size, retention, latency, and consistency must be established before choosing storage technology. ### Clarifying Questions to Ask - Are messages one-to-one, group, or both, and how large can groups become? - Is the guarantee accepted-at-least-once, displayed-once, or exactly-once user-visible behavior? - Must messages appear in the same order for every participant? - What history, search, edit, delete, attachment, and retention features are required? - How quickly must an offline user receive and synchronize missed messages? ### Part 1 — Define APIs and Schema Specify conversation creation, membership, send, history, and read-position APIs. Define the main records and indexes used by those access paths. #### What This Part Should Cover - Conversation and membership records with authorization checks. - Client request IDs and server message IDs. - A conversation-local sequence or another deterministic ordering key. - Keyset history pagination and per-member read position. ```hint Start from the history query The key used to fetch the next page of one conversation often determines the useful primary message index. ``` ### Part 2 — Walk Through Core Flows Describe creating a conversation, sending a message, delivering it to online members, reconnecting and reading missed history, and adding or removing a member. #### What This Part Should Cover - Durable acceptance before a success response. - Idempotent retries and duplicate downstream delivery. - Online notification as a hint, with history storage as the recovery source. - Membership checks tied to a version or effective sequence. ```hint Separate storage from notification A transient socket event can make chat feel live, but durable history must recover the truth after a disconnect. ``` ### Part 3 — Handle Consistency and Failure Explain concurrent sends, database failure, notification failure, stale membership, deletion, and observability. Give the invariants a repair job would check. #### What This Part Should Cover - Conditional sequence assignment or another per-conversation serialization rule. - Outbox delivery and idempotent consumers. - An explicit policy for messages racing with member removal. - Metrics for send latency, persistence failure, fan-out lag, duplicates, and missing history. ```hint Put races on one timeline Define whether membership is evaluated at request time, commit sequence, or delivery time so a removal race has one answer. ``` ### What a Strong Answer Covers - APIs and tables that support the stated flows without relying on a vague message broker. - Conversation-local order, idempotent sends, durable history, and reconnect recovery. - Explicit membership, deletion, and delivery semantics. - Failure handling and auditability proportional to the required scale. ### Follow-up Questions 1. How would you prevent a retried send from creating two visible messages? 2. What should happen when a user is removed while their send is committing? 3. How would a client detect a gap in locally cached history? 4. At what group size would write-time fan-out become impractical?