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/Google Drive: File Sync, Chunking, Delta Upload
45 min · senior
senior

You are designing a file synchronization service for a startup with 50 million daily active users. Users expect near real-time sync of files across devices with P99 latency under 200ms for metadata operations. Files can be large, so chunking and delta uploads are required to minimize bandwidth. End-to-end encryption is mandatory. The system must support offline edits and conflict resolution on reconnect.

Constraints
  • End-to-end encryption of file chunks and metadata
  • Support offline edits with conflict resolution on reconnect
  • P99 latency for metadata sync under 200ms
  • Chunking files into variable-sized encrypted blocks
  • Delta uploads to minimize bandwidth for file changes
📋
Guided Steps
1/5
Step 1
File Chunking and Storage
How would you design the chunking mechanism and storage backend for encrypted file chunks?
💡 Hint
Consider content-defined chunking and a scalable object store that supports immutable chunks.
Key Decision
Use content-defined chunking (e.g., Rabin fingerprinting) combined with Amazon S3 for immutable encrypted chunk storage to enable deduplication and scalable storage.
Interviewer Expectation
Mid: Names chunking and S3. Senior: Explains content-defined chunking reduces redundant uploads and why S3’s eventual consistency and high throughput fit immutable encrypted chunks.
⚠️Common Wrong Answer
Fixed-size chunking with a relational DB - leads to poor deduplication and relational DB cannot scale for large binary blobs.
Step 2
Delta Upload and Change Detection
How do you detect and upload only changed parts of files efficiently?
💡 Hint
Think about hashing chunks and comparing hashes before upload.
Key Decision
Use a Merkle tree of chunk hashes on the client and server; upload only chunks with missing hashes. Use SHA-256 for chunk hashes stored in DynamoDB for fast lookup.
Interviewer Expectation
Mid: Mentions chunk hashes and partial upload. Senior: Explains Merkle tree enables efficient subtree comparison and why DynamoDB’s single-digit ms latency suits hash metadata storage.
⚠️Common Wrong Answer
Upload entire files on every change - wastes bandwidth and increases latency.
Step 3
Metadata Sync and Conflict Resolution
How would you design metadata synchronization and conflict resolution for offline edits?
💡 Hint
Consider vector clocks or CRDTs for versioning and conflict detection.
Key Decision
Use Apache Cassandra with file_id as partition key to store metadata versions and vector clocks for conflict detection; client merges conflicts using last-writer-wins or manual resolution.
Interviewer Expectation
Mid: Names Cassandra for metadata. Senior: Explains Cassandra’s linear scalability with partition key and why vector clocks enable causal ordering and conflict detection.
⚠️Common Wrong Answer
Use a single master metadata server - becomes a bottleneck and single point of failure at 50M DAU.
Step 4
Low-Latency Sync and Notification
How do you ensure clients receive near real-time metadata updates with P99 < 200ms latency?
💡 Hint
Think about push notifications and streaming event buses.
Key Decision
Use Apache Kafka with file_id as partition key for ordered metadata event streaming, combined with WebSocket push notifications to clients for low-latency updates.
Interviewer Expectation
Mid: Mentions Kafka or push notifications. Senior: Explains Kafka partitioning ensures ordered events per file and WebSocket reduces polling overhead to meet 200ms P99 latency.
⚠️Common Wrong Answer
HTTP polling every few seconds - causes excessive load and high latency.
Step 5
End-to-End Encryption and Key Management
How would you implement end-to-end encryption for file chunks and metadata while enabling sync?
💡 Hint
Consider client-side encryption and secure key storage mechanisms.
Key Decision
Use client-side AES-256 encryption for chunks with keys derived from user passphrase; store encrypted keys in AWS KMS with envelope encryption and zero-knowledge key management.
Interviewer Expectation
Mid: Mentions client-side encryption. Senior: Explains envelope encryption with AWS KMS for secure key storage and how zero-knowledge prevents server access to plaintext.
⚠️Common Wrong Answer
Server-side encryption only - breaks end-to-end encryption guarantees.
🔌
API Design Challenge
Sketch 3 core API endpoints for the file sync system: uploading chunks, syncing metadata, and acknowledging sync completion.
Hints
  • How does the client send encrypted file chunks efficiently?
  • How does the client keep metadata in sync with minimal latency?
  • How does the client confirm successful sync to avoid redundant uploads?
📊
Scoring Rubric
▼ Show
Must Have - 60%
  • Use content-defined chunking with scalable object storage for encrypted chunks.
  • Implement delta uploads using Merkle trees and chunk hash metadata store.
  • Store metadata in a scalable NoSQL DB with partitioning for conflict resolution.
  • Use streaming event system with partitioning for low-latency metadata sync.
  • Implement client-side end-to-end encryption with secure key management.
Good to Have - 30%
  • Support offline edits with vector clocks or CRDTs for conflict detection.
  • Use WebSocket push notifications instead of polling for metadata updates.
  • Design APIs that minimize bandwidth and latency for chunk upload and sync.
Bonus - 10%
  • Explain trade-offs of fixed vs content-defined chunking at scale.
  • Discuss failure modes of Kafka partitions and recovery strategies.
  • Describe how envelope encryption integrates with user authentication.
Anti-patterns to Avoid
Fixed-size chunking causes poor deduplication and increases bandwidth usage, leading to inefficient storage and higher costs.
Uploading entire files on every change wastes bandwidth and increases latency, degrading user experience.
Single master metadata server creates bottlenecks and single points of failure, reducing system availability at 50M DAU.
HTTP polling at 50M DAU results in 50 million reconnects per minute just to check for messages, collapsing under load and causing high latency.
Server-side encryption only breaks end-to-end encryption guarantees, exposing user data to server compromise.
Using relational databases for chunk storage leads to scalability and performance issues due to inefficient handling of large binary blobs.
✅
Model Answer
▼ Reveal

The system uses content-defined chunking with Amazon S3 for encrypted chunk storage, Merkle trees and DynamoDB for delta uploads, Apache Cassandra with vector clocks for metadata and conflict resolution, Apache Kafka with WebSocket push notifications for low-latency metadata sync, and client-side AES-256 encryption with envelope encryption via AWS KMS for secure key management.

Key Decisions
  • Use Rabin fingerprinting for content-defined chunking to optimize deduplication and reduce upload bandwidth.
  • Store encrypted chunks immutably in Amazon S3 to leverage its scalability and durability.
  • Maintain chunk hash metadata in DynamoDB for low-latency existence checks enabling delta uploads.
  • Implement Merkle trees to compare file versions efficiently and upload only changed chunks.
  • Use Apache Cassandra with file_id partition key to scale metadata storage and support conflict resolution.
  • Employ vector clocks for causal versioning to detect and resolve conflicts from offline edits.
  • Stream metadata changes via Apache Kafka partitioned by file_id to ensure ordered delivery.
  • Push metadata updates to clients using WebSocket to meet P99 latency under 200ms.
  • Encrypt file chunks client-side with AES-256 and manage keys securely using AWS KMS envelope encryption to ensure end-to-end encryption.
  • Content-defined chunking (Rabin fingerprinting) reduces redundant uploads by detecting variable chunk boundaries.
  • Amazon S3 provides scalable, durable, and immutable storage for encrypted file chunks at petabyte scale.
  • Merkle tree of chunk hashes enables efficient delta uploads by comparing subtree hashes before uploading.
  • DynamoDB stores chunk hash metadata with single-digit millisecond latency for fast chunk existence checks.
  • Apache Cassandra stores file metadata with file_id partition key for linear scalability and conflict resolution.
  • Vector clocks enable causal versioning and conflict detection for offline edits and merges.
  • Apache Kafka streams metadata change events partitioned by file_id to ensure ordered delivery.
  • WebSocket push notifications reduce latency and server load compared to HTTP polling for metadata sync.
  • Client-side AES-256 encryption with envelope encryption via AWS KMS ensures end-to-end encryption and secure key management.
  • Offline edits supported by local metadata versioning and conflict resolution on reconnect.

Practice

(1/5)
1. A global video streaming service needs to reduce latency for users worldwide by caching content close to them. Which CDN component primarily handles this latency reduction?
easy
A. Origin server that stores the master copy of all content
B. DNS servers resolving domain names to IP addresses
C. Load balancers distributing requests among origin servers
D. Edge nodes located in Points of Presence (PoPs) near users

Solution

  1. Step 1: Identify latency reduction mechanism

    Latency is reduced by caching content closer to users, which is done by edge nodes in PoPs.

  2. Step 2: Eliminate other components

    Origin servers hold master content but are far from users; load balancers and DNS do not cache content.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Edge nodes cache content near users -> latency reduced [check]
Hint: Edge nodes cache near users for low latency [check]
Common Mistakes:
2. A messaging platform must handle 1 million messages per second with guaranteed ordering per conversation and durability. Which component best decouples message ingestion from fan-out delivery while preserving ordering?
easy
A. Use a Kafka topic partitioned by conversation ID
B. Use a relational database with row-level locks for ordering
C. Use a Redis pub/sub channel for message delivery
D. Use a simple in-memory queue per chat server

Solution

  1. Step 1: Identify Kafka's role in decoupling ingestion and delivery

    Kafka partitions by conversation ID ensure ordering per conversation and durability via replication.

  2. Step 2: Eliminate other options

    Redis pub/sub lacks durability and ordering guarantees; relational DBs can't handle 1M writes/sec with locking overhead; in-memory queues lack durability and don't scale across servers.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Kafka with conversation_id partition -> ordering within conversation guaranteed [check]
Hint: Kafka partitions preserve ordering and durability [check]
Common Mistakes:
3. If the feature store's ingestion Kafka topic is unavailable, what exactly breaks in the training pipeline's feature freshness guarantees?
medium
A. The training pipeline continues with stale features but logs a warning
B. The feature store falls back to batch recomputation, delaying training by hours
C. Feature ingestion blocks, causing training data to miss recent feature updates until Kafka recovers
D. The training pipeline silently drops missing features, causing inconsistent training data

Solution

  1. Step 1: Understand Kafka's role in feature ingestion

    Kafka streams feature updates to the store, enabling near real-time freshness.

  2. Step 2: Trace failure impact

    If Kafka is down, streaming ingestion halts. The system falls back to batch recomputation to update features, causing delays. Training cannot proceed with partial or dropped features without risking data quality.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Kafka outage triggers batch fallback, delaying freshness [check]
Hint: Kafka down -> batch recomputation fallback delays freshness [check]
Common Mistakes:
4. For a mobile chat app requiring low latency and offline support, which database choice best balances consistency and availability?
medium
A. Use a strongly consistent relational database with synchronous replication
B. Use a local NoSQL store with eventual sync to a cloud database
C. Use a distributed SQL database with global consensus for all writes
D. Use an in-memory cache with no persistence and rely on server-side storage

Solution

  1. Step 1: Analyze mobile app constraints

    Mobile apps need offline support and low latency; synchronous replication or global consensus cause high latency and poor offline support.

  2. Step 2: Evaluate database options

    Local NoSQL with eventual sync supports offline writes and syncs later, balancing availability and consistency.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Local NoSQL + eventual sync -> offline support and low latency [check]
Hint: Offline needs local store with eventual sync, not strict consistency [check]
Common Mistakes:
5. At 10x scale, which component in the route leak mitigation system is most likely to fail first, and why?
hard
A. The route validation workers, as CPU-intensive prefix checks saturate compute resources
B. The edge routers, because BGP session limits prevent scaling to more peers
C. The centralized configuration database, due to write contention and latency spikes
D. The monitoring dashboards, overwhelmed by alert volume causing UI crashes

Solution

  1. Step 1: Identify route validation worker bottleneck

    CPU-intensive prefix checks saturate compute resources first as scale increases.

  2. Step 2: Compare other components

    Config DB (A) can be sharded; edge routers (B) have limits but can be upgraded; dashboards (C) are less critical.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    CPU saturation in validation workers is first bottleneck at scale [check]
Hint: CPU-bound validation workers fail before others [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