Design a Cloud File Storage and Sync Service Like Google Drive

Quick Overview

Design a cloud file storage and sync service like Google Drive, where users upload files, organize folders, share them and keep every device in sync. It tests separating file content from metadata, chunked resumable uploads, a sync mechanism for offline devices, conflict handling, sharing permissions and scaling the metadata store.

Design a Cloud File Storage and Sync Service Like Google Drive

Company: Harvey

Role: Software Engineer

Category: System Design

Difficulty: medium

Interview Round: Onsite

Design a cloud file storage and sync service like Google Drive. Users upload and download files, organize them in folders, share files and folders with other people, and see the same files on every device, including changes made while a device was offline. The report gives only the name of the problem, so scale, feature scope and consistency expectations are open: settle them with the interviewer before designing. ```hint Bytes versus the tree Consider which data is large and rarely changes once written, and which is small, changes constantly and must stay consistent when a folder is moved. ``` ```hint Catching up a device Think about how a laptop that was offline for a day learns exactly what changed, without downloading or listing every file again. ``` ### Clarifying Questions - How many users and files are there, how much storage does a user have, and how large can a single file be? - Is real-time co-editing of documents in scope, or only storing and syncing files? - Which sharing features are needed: specific people with viewer or editor roles, link sharing, shared folders that appear in the recipient's own tree? - How quickly must a change on one device appear on the user's other devices and on collaborators' devices? - Are version history and a trash with restore required, and for how long? - What should happen when two devices change the same file while offline? ### What a Strong Answer Covers - Requirements and estimates for storage, file counts and request rates agreed first - Separation of file content (chunked blob storage) from metadata (folder tree, versions, permissions) - Resumable chunked uploads with an atomic commit, and uploads of only the changed parts of a file - A sync mechanism that lets each device catch up on exactly what changed, plus change notifications - Conflict handling for concurrent edits, moves and deletes without losing data - Sharing permissions with inheritance, a sharded metadata store, and the failure handling and monitoring that keep sync healthy ### Follow-up Questions - Two devices edit the same file offline and reconnect minutes apart. What does each user see afterwards? - A user moves a folder containing a very large number of files into a folder shared with their team. What has to change, and how quickly can it happen? - A shared folder with a very large number of members changes constantly. How do their devices learn about the changes without overloading the system? - How would you implement trash and version history, and when can a chunk's bytes actually be deleted?

Overview: Design a cloud file storage and sync service like Google Drive, where users upload files, organize folders, share them and keep every device in sync. It tests separating file content from metadata, chunked resumable uploads, a sync mechanism for offline devices, conflict handling, sharing permissions and scaling the metadata store.

Harvey logo
Harvey
Nov 4, 2026
mediumSoftware EngineerOnsiteSystem Design
1
0

Design a cloud file storage and sync service like Google Drive. Users upload and download files, organize them in folders, share files and folders with other people, and see the same files on every device, including changes made while a device was offline. The report gives only the name of the problem, so scale, feature scope and consistency expectations are open: settle them with the interviewer before designing.

Clarifying Questions Guidance

  • How many users and files are there, how much storage does a user have, and how large can a single file be?
  • Is real-time co-editing of documents in scope, or only storing and syncing files?
  • Which sharing features are needed: specific people with viewer or editor roles, link sharing, shared folders that appear in the recipient's own tree?
  • How quickly must a change on one device appear on the user's other devices and on collaborators' devices?
  • Are version history and a trash with restore required, and for how long?
  • What should happen when two devices change the same file while offline?

What a Strong Answer Covers Guidance

  • Requirements and estimates for storage, file counts and request rates agreed first
  • Separation of file content (chunked blob storage) from metadata (folder tree, versions, permissions)
  • Resumable chunked uploads with an atomic commit, and uploads of only the changed parts of a file
  • A sync mechanism that lets each device catch up on exactly what changed, plus change notifications
  • Conflict handling for concurrent edits, moves and deletes without losing data
  • Sharing permissions with inheritance, a sharded metadata store, and the failure handling and monitoring that keep sync healthy

Follow-up Questions Guidance

  • Two devices edit the same file offline and reconnect minutes apart. What does each user see afterwards?
  • A user moves a folder containing a very large number of files into a folder shared with their team. What has to change, and how quickly can it happen?
  • A shared folder with a very large number of members changes constantly. How do their devices learn about the changes without overloading the system?
  • How would you implement trash and version history, and when can a chunk's bytes actually be deleted?