System design interview question

Design a file sync service

Dropbox, Google Drive, OneDrive: “design a file sync service” looks like file upload and turns out to be about three harder things — sending only what changed, telling every other device within seconds, and never losing or mixing up a version. Here is how to walk into it, and then how to practise it until the answer is yours.

Practise File Sync

Multiple choicePick the design from four
Fill the gapsFill the gaps in one drawn for you
Build from scratchBuild it on a blank canvas

Practise it on a canvas

Free with an account.

The question, as an interviewer would set it

A file-sync service keeps a folder identical across a person's laptop, phone and work computer. Files range from small documents to videos of several gigabytes, and people often change a few bytes of a large file and save it again. Re-sending the whole file on every save would waste bandwidth and take far too long on slow connections. When a file changes on one device, the person's other devices should pick up the change within seconds, without each one repeatedly asking the server whether anything is new. The service must know exactly which version of which file every device has, and a file must never be lost or silently mixed with another.

What it is really testing

Every phrase that matters in the brief is a requirement in disguise. Spot them before you draw a single box.

“change a few bytes of a large file”
Store files as pieces, so a change re-sends only the pieces that changed.
“without each one repeatedly asking the server whether anything is new”
A connection held open so the server can announce a change.
“know exactly which version of which file every device has”
A transactional record of files, versions and devices.
“a file must never be lost”
Durable storage for every piece.

Back of the envelope

Users: 100 millionAn assumption to say out loud. If the interviewer has a number in mind, they will give it to you.
Stored: ~10 GB each → ~1 EB in totalBefore identical data is stored once; popular files are held by many people.
Saves: ~20 a day each → ~2 billion a day, ~23,000 a secondMost are small edits to files that already exist, which is why sending only the change matters.
Pieces: Files cut into ~4 MB pieces → a 2 GB file is ~500 of themA ten-kilobyte edit then re-sends one piece, not five hundred.

Questions to ask first

How large can a file be, and how often are large files edited in place?
How many devices does a typical person keep in sync?
What happens when the same file is edited on two devices while offline?
Is sharing between people in scope, or one person's own devices only?
Do we keep old versions, and for how long?

The trade-offs you will be pushed on

1.A few bytes of a large file change. What is sent, and how do you know which part changed?
2.How do the other devices find out about a change within seconds without asking again and again?
3.Two devices edited the same file offline. What happens when both come back?
4.

Now answer it

The same design always gets the same score, with the reason behind every requirement — then defend it against the trade-offs above.