Cloud Drive System Design Interview: Metadata, Chunking and Sync
A speaking-order walkthrough of the cloud drive system design interview: scope questions, the metadata/blob split, chunking, sync and the trade-offs to say out loud.
In a cloud drive system design interview you are scored on three things: how you scope the problem, whether the architecture holds together, and whether you can defend the choices you made. Feature completeness barely matters. This walkthrough follows the order you would actually speak it, with the sentences to say at each fork, so you can rehearse the session rather than memorise a diagram.
What does the interviewer actually want when they say "design a cloud drive"?
They want to hear you think. Three things get scored: scoping, a coherent architecture, and defended trade-offs. A design that covers half the features but explains none of its choices scores lower than a smaller design where every fork was named.
Open with a 30-second script. Say it almost verbatim:
"So the prompt is a cloud drive: users store files and sync them across devices. Before I draw anything, two questions. First, is this consumer or enterprise, because that changes sharing and permissions. Second, what's the priority: strong consistency for file listings, or availability when a region is slow? Assuming consumer, read-heavy, durability over latency, here's my plan for the next 35 minutes: five minutes on requirements and scale, fifteen on architecture, ten on sync and conflicts, five on trade-offs and what I'd do with more time. Does that work?"
Weak opening: "I'll use S3 and DynamoDB." Strong opening: state your assumptions first, then let the interviewer correct them. The second version invites a conversation; the first one makes them hunt for your reasoning.
Which requirements should you state before drawing anything?
Keep the functional list deliberately short and say it out loud: upload and download, sync across devices, share a file, version history, offline edits. That is five items, and it is enough.
Then invent numbers and say them. File sizes up to a few GB. Read-heavy: far more downloads and listings than uploads. Durability matters more than latency for stored bytes. Strong consistency for metadata, so a file you just renamed does not disappear on refresh. Rough numbers are fine; a stated number is worth more than a precise one you never say. If you want to reason about how these choices ripple, the consistency models walkthrough covers the same forks in more depth.
Close the section with one line of out-of-scope: "I'm leaving out real-time collaborative editing and malware scanning unless you want them." That tells the interviewer you chose the boundary rather than forgot it.
How do you split the system into metadata and blob storage?
Draw two planes. The metadata service holds the file tree, permissions and versions. The blob store holds immutable chunks of file content. Say why the split exists: metadata needs transactions and queries, blobs need cheap durable bytes. Different workloads, different stores.
Then walk the upload path end to end:
- The client asks the metadata service for a pre-signed URL for each chunk.
- The metadata service checks permissions and returns URLs.
- The client uploads chunks straight to the blob store.
- The client commits: it tells the metadata service the upload is complete.
- The metadata service writes the new version and moves the pointer.
Now say what happens if the commit fails. The chunks are orphaned in the blob store and no metadata points at them. The client retries the commit with the same upload ID; if it never succeeds, a garbage-collection job later removes unreferenced chunks. Naming this failure case before you are asked is one of the clearest signals that you have run real systems.
Why chunk files, and how big should a chunk be?
Reason from the user's problem, not the storage layer. A dropped connection should not mean re-uploading a 2 GB file. A small edit should not mean re-uploading the whole file. Chunking gives you resumable uploads, delta sync, and a cheaper retry after failure.
Fixed-size chunks are simple to implement and easy to reason about. Content-defined chunking handles inserts and shifts better, because an edit only changes the chunks around it. Pick one and give the reason: "I'll use fixed 4 MB chunks first for simplicity, and note that content-defined chunking is the upgrade if edits are common."
Then say the trade-off sentence: smaller chunks mean more metadata rows and more requests; larger chunks mean more re-upload on every edit. The interviewer is listening for whether you know the cost sits on both sides.
How does sync work when a user has a laptop, a phone and a browser tab open?
Describe a change feed. Each device holds a cursor into the feed, polls or subscribes, and pulls only changes after its cursor. The notification path can be a long poll or a push, but it carries only a signal, never file contents. Full bytes travel through the blob store, not the notification channel.
Give a short example so the mechanism becomes concrete. A file is renamed on the phone. The phone commits the new metadata, the change feed records it, and the laptop's long poll returns with the new name. It appears on the laptop in under a second, and the laptop never downloaded the file again because only metadata changed.
If you want to go deeper on the contract between client and server here, the API design walkthrough shows how to narrate it.
What do you do when two devices edit the same file offline?
State the honest options. Last-writer-wins is simple and loses data. Keep-both-copies preserves everything and clutters the folder. Operational transform or CRDTs merge edits properly and cost far more to build. Say which one you would ship first and why.
Walk a concrete conflict. Both devices edit the same document at 10:00 while offline. The phone syncs at 10:05 and its version becomes current. The laptop syncs at 10:20 with its own edit. Under last-writer-wins, the phone's edit vanishes silently and the user may never know. Under keep-both, the laptop's version becomes a new file named for the conflict, and both users see both edits.
Tie the choice back to the requirements: if the product must never lose data, keep-both beats silent overwrite. That sentence connects a product value to an engineering decision, which is exactly what the interviewer is testing.
Where do permissions, sharing and version history live?
Put access control lists in the metadata service and check them at the pre-signed URL step, not in the client. The client cannot be trusted, and the URL step is the last point before bytes move.
Version history is immutable blob versions plus a metadata pointer to the current one. The follow-up question is garbage collection: old versions cost money, so you need a retention policy and a job that deletes what falls outside it.
A sharing link is a capability token with an expiry. The trade-off is revocability versus caching: a long-lived link caches well but is hard to revoke, while a short-lived one is safer and forces more checks. Say which you would choose for a consumer product.
Which trade-offs should you name out loud before you finish?
Use a three-row table and say the sentence for each row.
| Decision | Option A | Option B | Sentence to say |
|---|---|---|---|
| Metadata consistency | Strong consistency | Availability | "I chose strong consistency for metadata because a stale file listing looks broken to users." |
| Chunk size | Small chunks | Large chunks | "Smaller chunks cost more metadata rows and requests; larger chunks cost more re-upload on edit." |
| Sync notification | Push | Poll | "Push is faster but harder to operate at scale; poll is simpler and good enough for most devices." |
Close with what you would do with more time: quotas, deduplication across users, regional replication. Then summarise your decisions in 20 seconds so the interviewer remembers your reasoning, not just your boxes.
What are the most common mistakes, and how do you practise?
Three mistakes come up again and again. Designing the UI instead of the backend. Skipping the metadata/blob split so everything becomes one vague store. Never stating a number, which makes the whole design unfalsifiable.
The fix for the opening line is a rewrite. Weak: "I'll use S3 and DynamoDB." Stronger: "Assuming consumer, read-heavy, durability over latency, here's my plan for the next 35 minutes."
Practise solo in 25 minutes: five minutes writing requirements and numbers, fifteen minutes drawing and narrating the architecture out loud, five minutes summarising trade-offs. Record it. Then review with three questions: did I say a number, did I name a trade-off, did I finish on time? If rambling is your habit, the answering plan for rambling pairs well with this routine.
Before you walk in
A cloud drive system design interview rewards a clear spine over a long feature list: scope, split metadata from blobs, chunk, sync, resolve conflicts, name trade-offs. Pick one number and one trade-off to say in the first five minutes, and rehearse the opening script until it sounds like you. Then run the 25-minute routine once more and listen for the moment you stop explaining and start listing.
You can find more practice frameworks on our blog.
Frequently asked questions
How much detail should I give on the client app versus the backend?
Spend most of your time on the backend and treat the client as a thin sync agent. Say that the client watches a change feed, uploads chunks directly and stores a local index. Then move on. Interviewers usually care about the server-side split, not the app's screens.
Do I need to estimate storage and bandwidth numbers, and how rough can they be?
Yes, but rough is fine. State an assumption for file sizes and read-to-write ratio, then use it to justify a choice such as chunk size or caching. A stated estimate that drives a decision is worth more than a precise calculation that changes nothing.
What if the interviewer keeps adding features like real-time collaboration?
Acknowledge the addition, say how it changes the design, and name the cost. Real-time collaboration pushes you toward CRDTs or operational transform and a much heavier sync layer. Offer to sketch it if time allows, but keep your original decisions visible so the interviewer can still follow your reasoning.
Is it better to draw one diagram or several as the design evolves?
Start with one diagram that shows the two planes and the upload path, then add a second only for sync or permissions. Several small diagrams are easier to follow than one that grows crowded, but each new one should answer a question the interviewer just asked.
How do I recover if I realise mid-interview that my chunking choice was wrong?
Say so plainly and explain the correction. Something like: "Actually, fixed chunks are wrong here because edits are common; content-defined chunking fits better." Interviewers tend to reward visible self-correction, because it shows you are evaluating your own design rather than defending it blindly.