Design Dropbox / Google Drive

Problem and Scope

Design a system like Dropbox, iCloud, or Google Drive that allows users to upload, download, and synchronize files across multiple devices. The system should be reliable, user-friendly, and able to handle a large number of users and files.

Start by confirming the core user journey, exclusions, success criteria, and the constraints that materially affect the architecture.

Requirements to Clarify

A strong answer should establish scope before choosing components.

Functional requirements:

• Allow users to upload files from various devices (mobile, web, desktop)
• Enable downloading of files to any device
• Automatically synchronize files across all devices when changes occur
• Notify clients when updates have been made to files
• Support all file types without specialized previewing capabilities

Non-functional requirements:

• Reliability - files should not be lost
• High availability - service should be accessible at all times
• Scalability - should handle the expected user and file load
• Performance - file transfers should be reasonably fast
• Security - files should be securely stored and transferred

Scale and Capacity

Use the workload to justify storage, partitioning, caching, and reliability decisions. Clarify or challenge these assumptions rather than treating them as unquestionable facts:

• 100 million registered users
• 1 million daily active users
• Each user uploads 1 file per day on average
• Average file size: 5 MB
• Maximum file size: 10 GB
• Storage limit per user: 15 GB

Architecture Discussion

Walk through the important read and write paths, identify ownership boundaries, and explain how the design behaves when dependencies fail. Cover these areas explicitly:

• Client applications (mobile, web, desktop)
• Load balancer for distributing traffic
• API servers for handling requests
• Storage solution for files
• Database for metadata
• Notification service for sync updates
• CDN for optimizing file delivery
• Ensuring file consistency across devices
• Handling large file uploads/downloads efficiently
• Providing near real-time synchronization
• Managing file conflicts when multiple devices edit the same file
• Ensuring data durability and availability
• Scaling the system to handle millions of users

Follow-up Questions

Expect the interviewer to test the consequences of your choices. Practise answering these questions with a concrete decision, its benefit, and its cost:

• Could you explain how your system would handle file conflicts when the same file is modified on two different devices?
  • Focus: Assess the candidate's answer to "Could you explain how your system would handle file conflicts when the same file is modified on two different devices" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
• What trade-offs did you consider when choosing your storage solution?
  • Focus: Assess the candidate's answer to "What trade-offs did you consider when choosing your storage solution" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
• How would your notification system scale to handle millions of users?
  • Focus: Assess the candidate's answer to "How would your notification system scale to handle millions of users" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
• How would your system handle partial uploads in case of network failures?
  • Focus: Assess the candidate's answer to "How would your system handle partial uploads in case of network failures" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
• How would you approach adding file versioning to your current design?
  • Focus: Assess the candidate's answer to "How would you approach adding file versioning to your current design" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.
• How would you ensure data durability in your system?
  • Focus: Assess the candidate's answer to "How would you ensure data durability in your system" for explicit assumptions, a workable mechanism, failure behavior, and consequential trade-offs.

Evaluation Rubric

MockMe evaluates the answer across the following dimensions. A complete answer should connect claims to requirements and explain consequential trade-offs.

• Requirements and scope (15%): Clarifies and prioritizes the required behavior for Allow users to upload files from various devices (mobile, web, desktop); Enable downloading of files to any device; Automatically synchronize files across all devices when changes occur. Establishes the constraints that materially affect Design Dropbox / Google Drive, including Reliability - files should not be lost; High availability - service should be accessible at all times. Strong evidence includes Separates the critical path from secondary features and resolves ambiguous requirements before choosing components.
• Architecture and interfaces (20%): Presents coherent ownership boundaries and end-to-end flows covering Client applications (mobile, web, desktop); Load balancer for distributing traffic; API servers for handling requests; Storage solution for files. Strong evidence includes Defines interfaces and traces important success, retry, and failure paths across the proposed components.
• Data and scaling (25%): Uses workload assumptions such as 100 million registered users; 1 million daily active users to justify capacity and partitioning decisions. Explains the data, state, or model strategy for Storage solution for files; Database for metadata; Ensuring data durability and availability. Strong evidence includes Quantifies a dominant workload, identifies the first bottleneck, and explains how the design evolves as that workload grows.
• Reliability, correctness, and safety (20%): Explains concrete failure behavior, recovery, and operational safeguards for Ensuring file consistency across devices; Ensuring data durability and availability; Reliability - files should not be lost. Strong evidence includes States the required correctness or consistency boundary and covers retries, partial failure, observability, and safe degradation.
• Communication and trade-offs (20%): Drives a structured discussion and compares consequential alternatives for Managing file conflicts when multiple devices edit the same file; Ensuring data durability and availability; Scaling the system to handle millions of users. Strong evidence includes Makes assumptions explicit, answers the question asked, and explains both the benefit and cost of major decisions.