Practice/Roblox/Design A To-Do List App With Multi-User Collaboration

Design A To-Do List App With Multi-User Collaboration

System DesignMust

Problem Statement

Design a to-do list application similar to Apple's Reminders app that allows users to create task lists, add and manage tasks, and share lists with other people for real-time collaboration. Multiple users should be able to view and edit the same list simultaneously, seeing each other's changes within seconds. Tasks support properties like title, due date, priority, notes, and completion status.

This problem tests your ability to design a system that balances real-time collaboration with data consistency. Unlike a simple CRUD application, shared to-do lists introduce concurrent edit conflicts (two users completing the same task simultaneously, reordering tasks at the same time, or editing a task's details while someone else deletes it). The system must handle these gracefully without losing data or confusing users. At scale, you need to support millions of users with thousands of actively shared lists, push updates in near real-time, and persist all data durably so nothing is lost when users close the app.

Interviewers at Roblox use this question to evaluate your understanding of real-time synchronization, conflict resolution strategies, efficient data modeling for hierarchical data (lists containing tasks), and the trade-offs between consistency models in a collaborative environment.

Key Requirements

Functional

• List and task management -- users create lists, add tasks with title, due date, priority, and notes, mark tasks complete or incomplete, and reorder tasks within a list
• Sharing and permissions -- list owners invite collaborators with viewer or editor roles, and can revoke access at any time
• Real-time sync -- when one collaborator edits a shared list, all other connected collaborators see the change within 2 seconds
• Offline support -- users can view and edit tasks while offline; changes sync automatically when connectivity is restored

Non-Functional

• Scalability -- support 10 million daily active users, 50 million lists, and 5,000 concurrently edited shared lists
• Latency -- local operations feel instant (under 50ms); remote changes propagate to collaborators within 2 seconds over stable connections
• Reliability -- no task or list data is ever lost, even during server failures or network partitions; achieve 99.9% uptime
• Consistency -- collaborators converge to the same list state within seconds; conflicts are resolved deterministically without user intervention

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Conflict Resolution for Concurrent Edits

When two users edit the same task or reorder tasks simultaneously, the system must merge changes without data loss. Interviewers want to see your understanding of consistency models and merge strategies.

Hints to consider:

• Consider CRDTs (Conflict-free Replicated Data Types) for operations like task completion toggling and text edits that need to merge automatically
• Use last-write-wins with logical timestamps for simple property updates (title, due date, priority) where the most recent change should take precedence
• Design a clear strategy for reordering: fractional indexing (assigning positions like 1.5 between 1 and 2) avoids conflicts when two users reorder simultaneously
• Handle the edge case where one user deletes a task while another user is editing it -- decide whether to resurrect or discard the edit

2. Real-Time Update Distribution

Pushing changes to all collaborators with low latency requires persistent connections and efficient message routing. Interviewers probe your understanding of WebSocket architecture and pub/sub patterns.

Hints to consider:

• Use WebSocket connections for real-time bidirectional communication between clients and servers
• Design a subscription model where clients subscribe to specific list IDs, and updates are published only to relevant subscribers
• Use Redis Pub/Sub or a message broker to coordinate between multiple application server instances when collaborators are connected to different servers
• Implement heartbeat mechanisms to detect stale connections and clean up subscriptions for disconnected clients

3. Offline Support and Sync Protocol

Mobile users frequently lose connectivity. Interviewers want to see how you buffer local changes and reconcile them with server state upon reconnection.

Hints to consider:

• Store a local operation log on the device that records every change made while offline
• On reconnection, send the accumulated operations to the server with a last-known sequence number so the server can identify what the client missed
• The server applies offline operations through the same conflict resolution logic used for real-time edits
• Consider how to handle the case where a list was deleted by another user while someone was editing it offline

4. Data Model and Storage Design

The hierarchical relationship between users, lists, and tasks, combined with sharing and real-time access patterns, requires thoughtful schema design.

Hints to consider:

• Model lists and tasks in a relational database (PostgreSQL) with a separate collaborators table tracking permissions per user per list
• Store task ordering using a position field with enough precision to allow insertions between existing tasks without rewriting all positions
• Index on (list_id, position) for efficient ordered task retrieval and on (user_id) in the collaborators table for fast "my lists" queries
• Consider event sourcing where every change is stored as an immutable event, enabling audit trails, undo functionality, and efficient sync

Suggested Approach

Step 1: Clarify Requirements

Ask the interviewer about the expected number of collaborators per list (2-5 family members, or hundreds of team members?). Clarify whether task ordering is important or if lists are unordered sets. Confirm whether offline support is in scope or if you should focus on connected users. Ask about additional features: subtasks, recurring tasks, reminders, attachments? Understand the consistency requirements: is it acceptable for collaborators to see slightly different states for a few seconds, or must updates be strictly ordered? Clarify whether the system needs to support undo/redo for collaborative edits.