Design a Real-Time Shared To-Do List

# Design a Real-Time Shared To-Do List Design a shared to-do list in which several people can create, edit, complete, delete, and reorder items while viewing the same list. Changes should appear quickly to connected collaborators, and a client that reconnects must converge on the authoritative state. Your design should explain the synchronous user-facing write path and identify work that may safely happen asynchronously. In particular, assess what would happen if every edit were first placed on a message queue before the caller received confirmation. ### Constraints & Assumptions - A list may be edited concurrently from web or mobile clients. - Users must not receive a success response for a change that has not reached durable authoritative storage. - Temporary duplicate deliveries and client reconnections are expected. - Exact traffic, list size, and retention targets should be established during requirements clarification rather than assumed. ### Clarifying Questions to Ask - Is ordering shared by all collaborators, and how should simultaneous reorder operations be resolved? - Must edits to one item be strictly ordered, or is eventual convergence with visible conflict handling acceptable? - Which permissions exist for owners, editors, and viewers? - How long may a client remain offline and still submit queued local edits? - Do completion notifications or audit-history updates need to block the edit response? ### What a Strong Answer Covers - A durable source of truth for lists, items, membership, per-item or per-list versions, and idempotency keys. - A write API that validates authorization and expected versions, commits the edit transactionally, then acknowledges the caller. - Real-time fan-out through WebSockets or a similar channel, with sequence or version information that lets clients detect gaps. - Explicit conflict behavior for concurrent edits and reorder operations instead of relying on arrival timing alone. - Reconnect recovery using a versioned snapshot or changes since a known cursor. - A precise boundary for queues: notifications, analytics, search indexing, and retryable fan-out may be asynchronous, while the authoritative edit should not wait in an uncommitted queue. - Failure handling for duplicate requests, lost socket messages, slow consumers, and a committed write whose fan-out is delayed. - Data partitioning, hot-list behavior, observability, access control, and abuse limits once scale requirements are known. ### Follow-up Questions 1. How would you preserve a stable shared order when two users drag different items at the same time? 2. A database commit succeeds but the real-time event is never delivered. How do clients recover without creating a second edit? 3. Which side effects could use a queue without changing the perceived correctness of the list? 4. How would the protocol change if clients could edit for hours while offline?