Bird
Raised Fist0

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

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
▶
Request Trace
Step 1/6
User Client

Uploads file metadata and delta info

Client sends file metadata and delta upload info to Metadata Service API

Protocol:HTTPS (REST API)
BeforeUser has a new or modified file with delta chunks ready to upload
AfterMetadata Service API received file metadata and delta info
Metadata Service API

Coordinates chunk upload

Metadata Service API instructs Chunk Upload Service to receive chunks

Protocol:gRPC
BeforeMetadata Service API has file metadata and delta info
AfterChunk Upload Service is ready to receive file chunks
Chunk Upload Service

Receives and stores chunks

Chunk Upload Service receives chunks, validates, and stores to Object Storage

Protocol:S3 API
BeforeChunk Upload Service is ready to receive chunks
AfterChunks are durably stored in Object Storage
Chunk Upload Service

Publishes change event

After storing chunks, publishes change event to Kafka topic

Protocol:Kafka Produce
BeforeChunks stored in Object Storage, no change event published yet
AfterChange Notification topic has new event for file update
Sync Worker Service

Consumes change event and updates metadata

Sync Worker consumes Kafka event, updates Metadata DB with new chunk info

Protocol:Kafka Consume and CQL
BeforeChange Notification topic has unprocessed file update event
AfterMetadata DB updated with new file metadata and chunk references
Metadata DB

Stores updated metadata and chunk references

Metadata DB persists the updated file metadata and chunk references for fast queries

Protocol:CQL
BeforeMetadata DB contains previous file metadata
AfterMetadata DB contains latest file metadata and chunk references
🏗️
Architecture Diagram
Architecture Diagram
┌───────────────┐
│  User Client  │
└───────┬───────┘
        │ HTTPS (REST API)
        ▼
┌───────────────────────────┐
│ Metadata Service API      │
│ - Receives file metadata  │
│ - Coordinates chunking    │
└───────┬───────────────────┘
        │ gRPC
        ▼
┌───────────────────────────┐
│ Chunk Upload Service      │
│ - Receives file chunks    │
│ - Validates and stores    │
└───────┬───────────────────┘
        │ S3 API
        ▼
┌───────────────────────────┐
│ Object Storage            │
│ (Amazon S3 or equivalent) │
└───────┬───────────────────┘
        │ Kafka Produce
        ▼
┌───────────────────────────┐
│ Change Notification       │
│ (Apache Kafka)            │
└───────┬───────────────────┘
        │ Kafka Consume
        ▼
┌───────────────────────────┐
│ Sync Worker Service       │
│ - Processes changes       │
│ - Updates Metadata DB     │
└───────┬───────────────────┘
        │ CQL
        ▼
┌───────────────────────────┐
│ Metadata DB               │
│ (Apache Cassandra)        │
└───────────────────────────┘
Design Rationale

This architecture shows a vertical flow for file sync with chunking and delta upload. The User Client sends file metadata and delta info to the Metadata Service API, which coordinates chunk uploads via gRPC to the Chunk Upload Service. Chunks are stored durably in Object Storage (e.g., Amazon S3). After chunk storage, a change event is published to Kafka, which the Sync Worker Service consumes to update the Metadata DB (Apache Cassandra). This design decouples chunk storage from metadata updates, enabling scalable, reliable sync with eventual consistency. Kafka ensures ordered, durable change notifications, while Cassandra stores metadata for fast queries. The vertical layout clarifies the sequential processing steps and component roles.

Primary Focus

✓

Practice

(1/5)
1. Without the graph database's relationship index, what exactly breaks during a shortest path query between two nodes?
medium
A. The query silently returns empty results without any error indication
B. The query falls back to scanning all nodes and edges, causing severe latency spikes
C. The query returns incorrect paths due to stale data in the index
D. The query crashes the database server due to unhandled exceptions

Solution

  1. Step 1: Role of relationship index

    The index enables efficient lookup of edges; without it, traversal cannot proceed correctly.

  2. Step 2: Behavior without index

    Queries relying on the index return empty results silently because no edges are found, not errors or scans.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Missing index causes silent empty results, not crashes or scans [check]
Hint: Missing index -> silent empty results, no errors or scans [check]
Common Mistakes:
2. For a global e-commerce platform requiring high availability and multi-region writes with eventual consistency, which key-value store choice is best and why?
medium
A. Use DynamoDB Global Tables for multi-region writes and automatic conflict resolution
B. Use Redis with master-slave replication across regions for low latency
C. Use Redis Cluster with cross-region sharding and manual conflict handling
D. Use a relational database with cross-region synchronous replication

Solution

  1. Step 1: Identify multi-region write and availability requirements

    Multi-region writes require conflict resolution and high availability without synchronous blocking.

  2. Step 2: Compare Redis and DynamoDB capabilities

    DynamoDB Global Tables support multi-region writes with built-in conflict resolution and eventual consistency; Redis lacks native multi-region write support.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    DynamoDB Global Tables -> multi-region writes with conflict resolution [check]
Hint: DynamoDB Global Tables handle multi-region writes natively [check]
Common Mistakes:
3. A startup expects rapid feature growth but limited initial traffic. They must choose between a monolith and microservices. Which architecture is best for minimizing early development overhead while allowing future scaling?
medium
A. Start with microservices to enforce strict service boundaries early
B. Start with a modular monolith and refactor to microservices when needed
C. Use a serverless architecture to avoid managing services
D. Build multiple small monoliths for each feature to isolate code

Solution

  1. Step 1: Evaluate development overhead vs scaling needs

    Serverless reduces initial infrastructure management overhead by outsourcing scaling and deployment.

  2. Step 2: Consider future scaling and limitations

    Serverless can limit control and cause cold start latency, but suits rapid early development with limited traffic.

  3. Final Answer:

    Option C -> Option C

  4. Quick Check:

    Serverless minimizes early overhead but may limit control later [check]
Hint: Serverless reduces early overhead but limits control [check]
Common Mistakes:
4. For a system requiring cost optimization with infrequent data access but occasional retrieval within hours, which storage architecture is preferable?
medium
A. Implement warm storage with HDDs and cold storage with object storage, migrating data based on access patterns
B. Use only hot storage with SSDs for all data to ensure fastest access
C. Archive all data immediately to tape storage to minimize cost
D. Store all data in cold storage with no tiering to simplify design

Solution

  1. Step 1: Analyze access and cost requirements

    Data is infrequently accessed but needs retrieval within hours, so cold storage alone is too slow.

  2. Step 2: Evaluate tiering benefits

    Warm storage offers moderate cost and latency; cold storage reduces cost further. Tiering balances cost and retrieval time.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Warm + cold tiering balances cost and retrieval latency [check]
Hint: Warm + cold tiering balances cost and latency [check]
Common Mistakes:
5. At 10x scale, which component in a circuit breaker-enabled microservice architecture is most likely to fail first, and why?
hard
A. The downstream service, because it cannot handle increased request volume despite circuit breaker protection
B. The circuit breaker state store, because centralized state tracking causes contention and latency under high concurrency
C. The load balancer, because it cannot distribute 10x more connections evenly
D. The client-side cache, because it grows too large and causes memory pressure

Solution

  1. Step 1: Analyze scaling impact on components

    Downstream service (A) is protected by circuit breaker; load balancer (C) scales horizontally; client cache (D) is local and less critical.

  2. Step 2: Identify circuit breaker state store bottleneck

    Centralized state store for circuit breaker metrics faces contention and latency at 10x concurrency, causing delays and incorrect breaker states.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Centralized circuit breaker state store bottlenecks first at scale [check]
Hint: Centralized circuit breaker state store bottlenecks first at scale [OK]
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