# Design Chat Deletion Semantics Under Concurrent Sends Design the backend of a chat application that supports creating threads, sending messages, reading thread history, deleting an individual message, and deleting an entire thread. Concentrate on deletion behavior and the race between `send_message` and `delete_thread` arriving concurrently on different servers. Define the user-visible contract: after thread deletion succeeds, can any concurrent message become visible, can an offline client resurrect old data, and what evidence is retained for audit or abuse handling? Explain storage, APIs, ordering, consistency, fanout, caches, and recovery. ### Constraints & Assumptions - Clients retry timed-out writes, so mutations need idempotency keys. - Thread participants may be connected to different real-time gateway servers. - Message storage and derived search, notification, and cache views may update asynchronously. - Exact retention requirements must be clarified rather than assumed. ### Clarifying Questions to Ask - Is deletion for one user, all participants, or permanent erasure? - Which operation should win when send and delete overlap? - Must deletion be immediately reflected on every online and offline client? - Are edits, legal holds, moderation records, and thread restoration in scope? ### What a Strong Answer Covers - A precise linearization rule for send-versus-delete - Conditional writes tied to thread state or generation - Tombstones, idempotency, and prevention of stale resurrection - Propagation to caches, search, notifications, and connected clients - Auditability, retention, observability, and failure recovery ### Follow-up Questions - How would per-user deletion differ from global deletion? - What happens if a delete event reaches search before a delayed create event? - How would end-to-end encryption affect server-side deletion? - How can clients reconcile after being offline during a thread deletion?