File sync system design

Questions to ask the interviewer

The design in short

File sync has two kinds of data, and the design is mostly about keeping them apart. The blocks are the file contents, cut into 4 MB pieces: huge, written once, read less often than the list. The list says which files exist and which blocks make each one: tiny, read all the time, and it must be exactly right.

Most traffic is a question, not a file. Every device asks again and again whether anything changed. Nearly every answer is no. So the fast, cheap path is the one that answers that question from the list, without touching a single block. Find out how often each device asks, multiply by the number of devices, and you have your busiest call.

Big files are a different problem. A project file can be a gigabyte. Pushing that through your app servers ties them up for a long time.

Boxes to decide on:

• whatever answers the change checks, and how many checks one machine can take
• where the list of files and blocks lives, and why it wants a database
• where the blocks live, and why a database is the wrong home for them

The main trade-off is freshness against load. Devices that ask more often see changes sooner, but every extra question is load on the list. The brief says a few minutes is fine, so use that slack instead of paying for speed nobody needs.

Reason about scale with two numbers: questions a second for the list, and gigabytes a day for the blocks. Each one grows a different part, so size each part for its own number, with room to spare.

Check with the interviewer how people work today: in one office, all online. Every answer is a requirement you can design for. The game draws both kinds of load on the board once your design runs.