Bird
Raised Fist0

Design Dropbox or Google Drive - File Sync, Chunking, Delta Upload

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
Design Dropbox or Google Drive - File Sync, Chunking, Delta Upload
Design a scalable file synchronization system with chunking and delta upload for billions of users
hardStorage and CollaborationFreq: high
Prerequisites:Object StorageChunking
⚙️
Functional Requirements
  • Support file synchronization across multiple devices for the same user with near real-time updates.
  • Implement chunking of files to enable partial uploads/downloads and efficient delta updates.
  • Detect and upload only changed chunks (delta upload) to minimize bandwidth usage.
  • Maintain version history and conflict resolution for concurrent edits.
  • Support offline edits and sync when device reconnects.
  • Provide metadata management for files and folders including permissions and sharing.
📊
Non-Functional Requirements
  • Support 2 billion daily active users globally.
  • Ensure 99.99% availability for file sync operations.
  • Achieve 100ms P99 latency for metadata operations (e.g., file listing, sync status).
  • Handle peak write throughput of 925K chunk uploads per second (derived in estimation).
  • Ensure data durability with replication and backups (e.g., 3x replication).
❓
Clarifying Questions to Ask
  • What is the average file size and typical chunk size for chunking?
  • How many devices per user do we expect on average?
  • What consistency model is required for file metadata and content?
  • Are files encrypted at rest and in transit?
  • What is the expected retention period for file versions?
  • Is cross-user file sharing in scope or only single-user sync?
Out of Scope
✗ Designing the user interface or client applications.
✗ Implementing advanced file sharing permissions or enterprise compliance features.
✗ Real-time collaborative editing (like Google Docs).
✗ Search indexing or content analysis of files.
📌
Assumptions
  • 2 billion daily active users (DAU).
  • Each user performs 40 file chunk uploads per day on average (including new files and delta chunks).
  • Average chunk size is 256 KB.
  • Average file size is 10 MB (approx 40 chunks per file).
⚡
QPS Calculation
write qps2B users × 40 chunks/day ÷ 86400 seconds ≈ 925,926 writes/sec
peak write qpsAssuming 3× peak factor: 925,926 × 3 ≈ 2.78M writes/sec
read qpsAssuming 2 reads per write (metadata + chunk fetch): 925,926 × 2 ≈ 1.85M reads/sec
💾
Storage Estimate
daily storage2B users × 40 chunks × 256 KB = 20.48 PB/day
retention days30
total storage20.48 PB/day × 30 days = 614.4 PB
with replication3× replication → 614.4 PB × 3 = 1.843 EB
🖥️
Server Estimate
metadata serviceAssuming 1 server handles 10K QPS metadata ops → 1.85M / 10K = 185 servers
chunk storage nodesAssuming each node stores 100 TB → 1.843 EB / 100 TB = 18,430 chunk storage nodes
🏗️
Architecture Diagram
Architecture Diagram
           +----------------------+
           |   Client Devices     |
           +----------+-----------+
                      | Sync API Calls
                      v
           +----------+-----------+
           | Metadata Service API |
           +----------+-----------+
                      | Metadata ops
                      v
           +----------+-----------+
           | Metadata DB (Cassandra)|
           +----------+-----------+
                      | Chunk metadata
                      v
           +----------+-----------+
           | Chunk Upload Service |
           +----------+-----------+
                      | Chunk data
                      v
           +----------+-----------+
           | Object Storage (S3)  |
           +----------+-----------+
                      |
                      v
           +----------+-----------+
           | Change Notification  |
           | (Kafka)              |
           +----------+-----------+
                      |
                      v
           +----------+-----------+
           | Sync Worker Service  |
           +----------------------+
🧩
Components
Metadata Service API
Handles client requests for file metadata operations such as listing, versioning, and conflict resolution.
Why thisStateless microservice layer using gRPC for low-latency metadata operations and horizontal scaling.
Why notMonolithic REST API would not scale efficiently to 2B users and 1.85M QPS reads.
Metadata DB (Apache Cassandra)
Stores file and chunk metadata with high write throughput and linear horizontal scalability.
Why thisCassandra supports wide-column storage, tunable consistency, and can handle 2.78M writes/sec with proper sharding.
Why notPostgreSQL requires complex manual sharding and B-tree writes do not scale linearly at this write volume.
Chunk Upload Service
Receives chunk uploads from clients, validates, and writes chunk data to object storage.
Why thisStateless service that can horizontally scale behind a load balancer to handle peak 2.78M chunk uploads/sec.
Why notDirect client upload to object storage lacks validation and metadata consistency guarantees.
Object Storage (Amazon S3 or equivalent)
Stores immutable chunk data with high durability and availability.
Why thisS3 provides 99.999999999% durability, automatic replication, and virtually unlimited storage capacity.
Why notHDFS or local storage clusters do not provide the same durability or global availability guarantees.
Change Notification (Apache Kafka)
Streams file and chunk change events to sync workers and other downstream consumers.
Why thisKafka supports high-throughput, ordered event streaming with partitioning for scalability and fault tolerance.
Why notRabbitMQ or Redis Pub/Sub do not scale as well for multi-million events per second with persistence.
Sync Worker Service
Processes change events to update client sync states, trigger notifications, and resolve conflicts asynchronously.
Why thisDecouples client sync logic from upload path, enabling eventual consistency and scalable background processing.
Why notSynchronous processing in upload path would increase latency and reduce availability.
🔄
Data Flow
1
Client Device → Metadata Service API
Client requests file metadata and sync status
Low-latency metadata fetch to determine which chunks need upload/download
2
Client Device → Chunk Upload Service
Client uploads changed file chunks
Chunk Upload Service validates and stores chunks in object storage
3
Chunk Upload Service → Object Storage (S3)
Store immutable chunk data
Chunks are stored with high durability and availability
4
Chunk Upload Service → Metadata DB (Cassandra)
Update chunk metadata and version info
Metadata DB tracks chunk locations and versions
5
Metadata DB → Change Notification (Kafka)
Publish change events
Notify sync workers of updates
6
Change Notification (Kafka) → Sync Worker Service
Process change events
Sync workers update client sync states and resolve conflicts
7
Sync Worker Service → Client Device
Push sync notifications
Clients receive updates to sync files

Practice

(1/5)
1. Without the consistent hashing ring metadata, what exactly breaks in a distributed cache system when a client requests a key?
medium
A. The cache nodes lose synchronization and data becomes corrupted
B. The cache node receiving the request cannot determine the correct node, causing request failure or indefinite retry
C. The client receives stale data from an outdated cache node
D. The system falls back to a centralized database for all requests, increasing latency

Solution

  1. Step 1: Role of consistent hashing ring metadata

    The ring metadata maps keys to nodes; without it, nodes cannot route requests correctly, leading to inconsistent data placement.

  2. Step 2: Consequence of missing ring metadata

    Without this metadata, nodes lose synchronization on key ownership, causing data corruption as writes go to wrong nodes; request failure (The cache node receiving the request cannot determine the correct node, causing request failure or indefinite retry) is secondary, and fallback (The system falls back to a centralized database for all requests, increasing latency) is not automatic.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Missing ring metadata causes data corruption due to lost key-node mapping [check]
Hint: No ring metadata -> lost key-node mapping -> data corruption [check]
Common Mistakes:
2. If the load balancer's health check component is removed, what exact failure occurs when a backend server crashes unexpectedly?
medium
A. The load balancer continues sending requests to the crashed backend, causing client timeouts
B. Clients receive error responses directly from the crashed backend server
C. The backend server automatically restarts and recovers without affecting traffic
D. The load balancer immediately detects the crash and reroutes traffic seamlessly

Solution

  1. Step 1: Understand health check role

    The health check component detects backend server crashes and informs the load balancer to stop routing traffic to failed servers.

  2. Step 2: Trace failure without health checks

    Without health checks, the load balancer is unaware of backend crashes and continues routing requests to the failed server, causing client requests to hang or timeout (The load balancer continues sending requests to the crashed backend, causing client timeouts).

  3. Step 3: Eliminate other options

    The load balancer immediately detects the crash and reroutes traffic seamlessly is false because detection is missing. The backend server automatically restarts and recovers without affecting traffic is unrelated to load balancer behavior. Clients receive error responses directly from the crashed backend server is incorrect because crashed servers cannot respond.

  4. Final Answer:

    Option A -> Option A

  5. Quick Check:

    No health checks -> load balancer sends requests to crashed backend causing timeouts [check]
Hint: No health checks -> requests sent to dead servers cause timeouts [check]
Common Mistakes:
3. At 10x scale, which component is most likely to fail first and why in Facebook Messenger's group chat system?
hard
A. Chat Servers because WebSocket connections are stateful and cannot be resharded easily
B. The database because it cannot handle 10x write throughput
C. Kafka brokers because partition count cannot be increased dynamically
D. Presence service because Redis TTL expiration causes message loss

Solution

  1. Step 1: Analyze stateful components at 10x scale

    Chat Servers maintain WebSocket connections bound to server memory, limiting horizontal scaling.

  2. Step 2: Compare other components

    Databases and Kafka can be sharded or scaled; Redis TTL issues cause transient problems but not first failure.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Stateful WebSocket connections -> Chat Servers bottleneck at scale [check]
Hint: Stateful WebSocket binds connections -> Chat Servers bottleneck [OK]
Common Mistakes:
4. At 10x traffic scale, which component is most likely to fail first and why?
hard
A. The chat servers because WebSocket connections are stateful and cannot be resharded easily
B. The load balancer because it cannot distribute connections evenly at high scale
C. The database because it cannot handle increased write throughput without sharding
D. The CDN because cache invalidation delays increase latency

Solution

  1. Step 1: Identify stateful bottlenecks

    Chat servers maintain WebSocket connections statefully, binding clients to specific servers.

  2. Step 2: Scaling challenges

    At 10x scale, adding servers doesn't move existing connections, causing uneven load and resource exhaustion.

  3. Step 3: Why others fail later

    Databases can be sharded (The database because it cannot handle increased write throughput without sharding), load balancers scale horizontally (The load balancer because it cannot distribute connections evenly at high scale), and CDNs handle scale well (The CDN because cache invalidation delays increase latency).

  4. Final Answer:

    Option A -> Option A

  5. Quick Check:

    Stateful WebSocket servers -> resharding limits cause first failure [check]
Hint: Stateful WebSocket servers fail first at scale due to reshard limits [OK]
Common Mistakes:
5. At 10x scale, which component in an async messaging chat system fails first and why?
hard
A. The database, because increased writes cause lock contention
B. The message queue brokers, due to partition leader overload
C. The chat servers, because WebSocket connections are stateful and cannot be resharded easily
D. The delivery workers, because retry queues grow exponentially

Solution

  1. Step 1: Analyze stateful components and scaling challenges

    Databases (The database, because increased writes cause lock contention) can be scaled with sharding and replicas. Message queue brokers (The message queue brokers, due to partition leader overload) scale horizontally with partitions. Delivery workers (The delivery workers, because retry queues grow exponentially) can be scaled with backpressure.

  2. Step 2: Identify chat servers as stateful WebSocket connection holders

    Chat servers maintain persistent WebSocket connections bound to server memory, making resharding or migration difficult at scale.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Stateful WebSocket servers -> first bottleneck at 10x scale [check]
Hint: Stateful WebSocket servers limit horizontal scaling first [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard