Design Dropbox

Each phase is what the interviewer expects you to do and say. Concrete steps, not topic hints. The diagrams are what you sketch on the board.

1. 1

   Clarify Requirements and Scale

   5 min

   GoalPin the three problems (transfer, sync, storage), get the scale numbers on the board, and lock in the sync-latency budget so every choice afterward has a target.

   Do & Say

   1. ASK·1ASK: “There are three problems hiding inside file sync”: “Transfer efficiency”, “multi-device sync”, “storage efficiency”. “Can I walk through each before I draw anything?” Get the nod, then proceed.
   2. WRITE·2Write the scale numbers: “500M users”, “50M DAU”, “10B files”, “100PB total”, “1M uploads/minute peak”, “2MB avg file size”. Say: “The 2MB average matters because it means most files are small enough that chunking metadata becomes a bigger problem than chunking math.”
   3. SAY·3Lock the sync latency budget: “under 1 second for metadata propagation”, “under 10 seconds for a small file to land on a second device”, “files up to 50GB”, “version retention 180 days or 100 versions”. Wait for confirmation.
   4. SAY·4Get the durability story right: “11 nines on object storage”, “99.99% on the service”. “The asymmetry matters because the architecture will treat the object store as the durable substrate and PostgreSQL as the metadata index, not the other way around.”
   5. SAY·5Park out of scope. In scope: “chunking”, “dedup”, “the sync protocol”, “conflict resolution”, “the upload pipeline”. Defer: “sharing permissions”, “team workspaces”, “search to the end if there's time”.

   Interviewer is grading: You frame the three problems before drawing anything. You quote the 2MB average and use it as a justification later, not just a number you wrote down.

2. 2

   Chunking and Dedup

   10 min

   GoalPut three chunking strategies on the board, kill two with concrete failure modes, defend CDC with the insertion example.

   Draw on the board
   Do & Say

   1. SAY·1Put three approaches on the board: “full-file upload”, “fixed-size chunking”, “content-defined chunking”. Cross them off as you go.
   2. WATCH·2Kill full-file fast: “A 100MB spreadsheet with a 1KB edit becomes a 100MB upload.” “At 1M uploads/minute that's bandwidth suicide.” “Only viable below maybe 1MB.” Cross it off.
   3. WATCH·3Kill fixed chunking with the insertion example: “20MB file into five 4MB chunks.” “Insert 1KB at byte 100, every byte after shifts so every chunk hash changes.” “Fixed chunking degrades to full-file upload for middle-of-document edits.” Cross it off.
   4. SAY·4Defend CDC: “Slide a 48-byte window with Rabin fingerprint.” “Boundary when hash mod TARGET equals zero, TARGET tuned for 4MB average.” “Min 2MB, max 8MB to bound pathological cases.” “Boundaries are content-defined, so the 1KB edit only changes its own chunk.”
   5. DRAW·5Sketch the two-hash idea: “Rabin is cheap, O(1) per byte position, but it has collisions.” “SHA-256 is expensive but content-addressable.” “Rabin finds candidate boundaries and matches, SHA-256 confirms identity.” “Think metal detector versus gemologist, you'd never use either alone.”
   6. SAY·6Connect chunking to dedup: “Because SHA-256 is deterministic, two users uploading the same file produce identical chunk hashes.” “Server stores one copy and 500 pointers.” “The 500-person company onboarding example: a 50MB handbook becomes 50MB total, not 25GB.”

   Interviewer is grading: You volunteer the insertion failure mode for fixed chunking without prompting. You name the 48-byte window and Rabin fingerprint as the specific weak hash, not 'a rolling hash'.

3. 3

   High-Level Design (the three planes)

   10 min

   GoalDraw control, data, event planes separately. Make presigned URLs and the metadata write the two load-bearing decisions, label arrows with QPS or bandwidth.

   Draw on the board
   Do & Say

   1. DRAW·1Draw three planes in three lanes: “control (metadata, orchestration)”, “data (chunks, metadata storage)”, “event (Kafka for sync fan-out)”. Say: “The whole point of this split is that file bytes never touch the API server fleet.” “They go straight to object storage via presigned URLs.”
   2. SAY·2Walk the upload critical path: “Client computes chunk hashes locally, calls /upload/init with the hash list only.” “Dedup Service checks each hash, Bloom filter first then PostgreSQL to verify.” “Server returns presigned URLs only for chunks that don't exist yet.” Label that arrow “hashes, not bytes”.
   3. SAY·3Justify presigned URLs in one breath: “At 100GB/sec of upload ingress at peak, routing bytes through the API fleet would need thousands of proxy nodes just to forward data.” “Presigned URLs eliminate that.” “The byte path is client to object store, server is only in the metadata path.”
   4. DRAW·4Sketch the sync fan-out: “On finalize, Sync Service writes the version to PostgreSQL and publishes to Kafka.” “Partitioned by user_id_hash mod 1000 so all events for one user stay ordered.” “WebSocket Gateway consumes, looks up the device's pod in Redis, pushes CHANGE.”
   5. SAY·5Name the WebSocket sizing: “40M concurrent connections at 30% online concurrency”, “500K per pod max”, “80 WebSocket pods”. “Memory-bound at 15KB per connection, not CPU-bound.” Write “40M / 80 pods” on the diagram.
   6. SAY·6Name the metadata sharding: “PostgreSQL + Citus, sharded by user_id.” “Almost every query is user-scoped, so Citus co-locates files, versions, version_chunks on the same shard.” “Cross-shard joins basically don't happen.” “27TB total across 50+ worker nodes.”

   Interviewer is grading: You name 'bytes never touch the API server' as the load-bearing decision. You quote the 80 WebSocket pods and the user_id sharding, not generic 'partition for scale'.

4. 4

   Deep Dive: Sync Protocol and Conflict Resolution

   10 min

   GoalTwo sub-dives. The dual-channel sync (WebSocket push + cursor catch-up), and last-writer-wins-with-conflicted-copy for concurrent edits.

   Draw on the board
   Do & Say

   1. SAY·1Sub-dive 1, the sync protocol. Frame it: “A device that has been online the whole time can rely on WebSocket pushes.” “A device that was offline for two weeks can't.” “So we need two channels.”
   2. SAY·2WebSocket path: “Kafka delivers to WebSocket Gateway, which pushes CHANGE to the user's other online devices within seconds.” “Device fetches the new version's chunk list and downloads only chunks it doesn't have locally.” “A 2-chunk edit on a 100MB file is 8MB, not 100MB.”
   3. SAY·3Cursor-based catch-up: “A device that comes back online reads its last cursor from local SQLite, calls /v1/sync/changes with that cursor, server returns paginated changes since then.” “Cursor encodes timestamp plus shard identifier.” “WebSocket gives speed and cursors give correctness, so no change is ever missed.”
   4. SAY·4Sub-dive 2, conflict resolution. Frame it with the concrete example: “Alice has budget.xlsx synced.” “Laptop goes offline. Both laptop and phone edit.” “Phone uploads first, server creates v6.” “Laptop comes back, tries to upload with base_version=5 but current is 6.” Walk through it.
   5. SAY·5Pick last-writer-wins-with-conflicted-copy: “Server accepts the laptop's edit as v7, then creates a new file called "budget (conflicted copy - Phone - 2026-03-10).xlsx" from the v6 content.” “Both devices get notified.” “Alice sees both files and decides what to do.”
   6. SAY·6Defend the choice: “For a general-purpose sync platform that handles binary files like images, videos, compiled documents, there is no universal merge algorithm.” “Last-writer-wins plus conflicted copy is the safest.” “Data loss is worse than a conflict notification.” Quote the rate: “Less than 0.01% of file operations in practice.”
   7. SAY·7Name the cycle-prevention mechanic: “Each upload carries a base_version that pins the parent.” “That kills sync loops where device A syncs to B, B syncs back to A, repeat forever.” “A device only accepts a version with a strictly newer base_version than its local copy.”

   Interviewer is grading: You volunteer the dual-channel architecture (WebSocket plus cursor) before being asked about offline support. You can recite the conflicted-copy filename format and explain why it's better than rejecting the laptop's write.

5. 5

   Trade-offs, Bottlenecks, and Wrap-up

   5 min

   GoalName the deliberate trade-offs (delta granularity, sync latency, dedup vs encryption), give the GC plan for chunk reference counting, close with one sentence.

   Do & Say

   1. SAY·1Trade-off 1, CDC over rsync as the primary model: “CDC gives cross-user dedup since hash identity is global.” “rsync only compares old vs new of the same file.” “Production uses CDC primary, rsync-style delta when applicable.” “50%+ storage savings from cross-user dedup is the bigger win at this scale.”
   2. SAY·2Trade-off 2, dedup versus end-to-end encryption: “Cross-user dedup requires the server to see plaintext chunk hashes.” “True end-to-end encryption with per-user keys would kill that, because the same plaintext becomes different ciphertext for each user.” “The design accepts server-side hashing, which is what allows the 50% storage savings.”
   3. SAY·3Bottleneck: “Chunk reference counting.” “12.5B chunks, ref_count up on new versions, down on expiry.” “Premature decrement deletes a referenced chunk.” Mitigation: “24-hour quarantine plus weekly reconciliation scanning for discrepancies”. “Even on premature delete, re-upload of the same content rehashes to the same key, chunk reappears.”
   4. SAY·4Bottleneck: “Object storage rate limits.” “Most providers cap at 3,500 PUTs per second per prefix.” “At 25K PUTs/sec we need ~256 prefixes.” “We hash the chunk ID into a prefix structure like chunks/a1/b2/a1b2c3... so writes spread across 65,536 prefixes naturally.” “Per-prefix load drops to under 1 PUT/sec.”
   5. SAY·5Close: “Three planes.” “Control for metadata, data via presigned URLs so bytes skip the server, event for fan-out via Kafka and WebSockets.” “CDC plus SHA-256 gives delta sync and cross-user dedup.” “LWW plus conflicted copy preserves both edits.” “Biggest risk is chunk ref-count drift, mitigated by 24h quarantine.”

   Interviewer is grading: You volunteer the dedup-versus-E2EE tension without being asked. You quote the 24-hour quarantine and the 3,500 PUT-per-prefix limit, not generic 'we batch writes'.

Questions an interviewer is likely to ask after your walkthrough. Rehearse the short answer.

1. Why content-defined chunking instead of fixed-size?
2. Why does the file byte path skip the API fleet?
3. How does the client know which chunks to upload?
4. Walk me through the offline-device sync case.
5. What happens if two devices edit the same file simultaneously?
6. How do you handle chunk garbage collection without losing data?
7. What about the object-storage prefix hot-spot?
8. Why PostgreSQL + Citus instead of DynamoDB or Cassandra?