Design Messaging With Message Deletion
Company: Databricks
Role: Software Engineer
Category: System Design
Difficulty: medium
Interview Round: Onsite
Design a real-time messaging application with channels or conversations, message history, and message deletion. Focus especially on how deletion behaves across storage, caches, search, connected clients, and offline clients.
### Constraints & Assumptions
- Messages have stable IDs and belong to one conversation.
- Clients may reconnect after being offline and may receive duplicate events.
- A deletion must preserve enough information for clients to converge without exposing deleted content.
- The exact retention, legal, and authorization policy is not prescribed; ask before selecting hard versus soft deletion.
### Clarifying Questions to Ask
- Who may delete a message, and is there a time limit?
- Should replies, reactions, and attachments remain?
- Is deletion reversible or auditable?
- Must search removal be immediate?
- What should an offline client display when it reconnects?
### What a Strong Answer Covers
- Message IDs, conversation ordering, and pagination
- An authorized, idempotent deletion transition
- Tombstones or versioned delete events
- Fan-out to online and offline clients
- Cache, search, attachment, and replica cleanup
- Race handling for edit, react, reply, and delete
### Follow-up Questions
- Support deletion of an entire conversation.
- Meet a strict erasure requirement across backups.
- Preserve ordering during a regional failover.
Overview: Design real-time messaging with conversations, history, and deletion that converges across storage layers and online or offline clients. Clarify authorization and retention, then address duplicate events, edit/reaction races, search and attachment cleanup, reconnect behavior, regional failover, audits, and strict erasure.
Read the full Databricks Software Engineer interview experience this question came from