Design a Cloud File Storage and Sync Service and Defend Your API and Latency Choices

You are asked to design a cloud file storage and synchronization service along the lines of Dropbox. Each user has a folder on every device they sign in from. When they add, edit, move or delete a file there, the change is uploaded and then reflected on their other devices, and users can share files and folders with other people. The interviewer keeps the session conversational and stops you at decisions to ask why you made them. Expect to defend choices such as using REST or gRPC for a given interface, and to point out where latency could hurt users and how you would reduce it. No scale figures were reported for this interview, so propose your own and state them as assumptions before you estimate. ### Constraints and Clarifications - Clients run on desktop, mobile and the web; desktop and mobile clients can stay offline for long periods and must catch up afterward. - Files range from small text documents to multi-gigabyte videos, and large uploads may be interrupted. - Durability of user files is non-negotiable: an acknowledged change must never be lost. - Choose your own scale assumptions (users, devices, stored bytes, change rate) and say them out loud. ### Clarifying Questions - Is version history in scope, and how long should old versions be kept? - When two devices edit the same file and neither saw the other's change, should one edit win, or should both be kept? - Can collaborators edit shared folders, or only view them? - Which experience matters more: fast propagation of small edits, or high throughput for large uploads? - Are there encryption, retention or data-residency requirements? ### Part 1 — Requirements, estimates and the core design State the functional and non-functional requirements, size the system, and sketch an end-to-end design: what runs on the device, which backend services exist, where file contents and file metadata live, and how a new file travels from one device to storage and then to the user's other devices. ```hint Split bytes from bookkeeping File contents are large and rarely change once written; the record of which files exist, where, and in which version is small and changes constantly. Ask whether both belong in the same kind of store. ``` #### What This Part Should Cover - Requirements and back-of-the-envelope sizing, stated as explicit assumptions - A data model that separates file metadata from file content - Upload and download paths, including resumable transfer of large files and not re-sending unchanged data - How other devices find out that something changed ### Part 2 — Sync, offline devices and conflicts Walk through what happens when a file changes on one device and must appear on another, including a device that comes back online after days away and two devices that edited the same file independently. ```hint What does a device remember? Think about the smallest piece of state a device could keep so that it can ask the server for exactly the changes it has not seen yet. ``` #### What This Part Should Cover - A change log or cursor mechanism that lets any device catch up incrementally - A defined conflict policy and how the user experiences it - Ordering and consistency guarantees for metadata versus file contents ### Part 3 — Defending protocol and latency decisions The interviewer asks why you chose REST or gRPC for each interface in your design, and where users would feel latency. Justify each protocol choice, then walk through the latency on the upload, download and change-propagation paths and how you would measure and reduce it. ```hint Different callers, different constraints A browser, a desktop agent you ship yourself, an internal service and a multi-gigabyte transfer each limit your options in a different way. ``` #### What This Part Should Cover - A justified protocol choice per interface rather than one blanket answer - The main sources of user-visible latency on each path - Concrete mitigations and how their effect would be measured ### What a Strong Answer Covers - Drives the discussion: requirements first, a working end-to-end design next, then deep dives - Pairs every major decision with its reason and an alternative that was considered - Handles large files, offline devices and concurrent edits explicitly rather than assuming them away - Covers durability, failure recovery and observability, not only the happy path - Brings a senior leader's lens: cost, operational ownership, and how the work would be split across teams ### Follow-up Questions - A user with hundreds of thousands of small files signs in on a new laptop. How do you make the first sync fast without overwhelming the metadata tier? - How would you add version history and restore without storing a full copy of every version? - A shared folder has thousands of members. How do you notify all of their devices efficiently when one file changes? - How would you change the chunking scheme for new uploads without breaking older clients?