Real-Time Sync Mechanics and Storage Data Model for Google Docs and Drive

This is a technical question for a product manager candidate. Google's file and document products both have to keep data in sync. The Drive app keeps a user's files the same on their laptop, their phone and the cloud, and Google Docs keeps one document the same for every person editing it at the same moment. Explain how you would build the sync feature for one of them (or both), then explain how you would design the database behind Google Drive. ### Clarifying Questions - Should the sync discussion focus on the Drive app keeping local files in step with the cloud, on several people co-editing one Doc at once, or on both? - Do people need to keep editing while offline, with their changes merged once they reconnect? - Should storage cost be weighed alongside speed and reliability in the database design? - How deep should the answer go: components and data flows, or table-level schemas, keys and indexes? ### Part 1 — Syncing changes across devices and collaborators Describe how a change made in one place reaches every other copy: what the client sends, who decides the order of edits that arrive at nearly the same time, and what happens when two changes to the same content collide or when a device comes back after being offline. ```hint Send the change, not the copy Think about what should travel over the network when someone types one word in a long document or edits part of a large file, and about which component, if any, has the final say when two edits arrive together. ``` #### What This Part Should Cover - The end-to-end path of an edit and the unit of change that is sent and stored - How concurrent and offline edits are reconciled, and why a live document and a binary file need different conflict handling - Durability and recovery when a connection drops or a server fails in the middle of editing ### Part 2 — The database behind Drive Design how Drive stores its data: the entities and tables, how folders, file versions and sharing are represented, which queries must be fast, and how the design scales to a very large number of users and files. ```hint Not all data is alike Compare the size and access pattern of a file's contents with those of its name, folder, owner and sharing settings. What does that difference suggest about where each should live? ``` #### What This Part Should Cover - Core entities and their relationships, including folders, versions, sharing and a record of changes that devices can sync from - The main read and write paths and the keys or indexes that keep them fast - Partitioning, replication, and which data needs strong consistency versus eventual consistency ### What a Strong Answer Covers - Correct sync mechanics: incremental changes, a clear ordering or merge rule for concurrent edits, and a way for devices to catch up on what they missed - Named trade-offs with a reasoned choice, such as server-ordered transformation versus merge-friendly data types, and keeping both versions versus letting the last writer win - A data model that separates file contents from information about files and supports listing, version history, sharing and incremental sync without full scans - Scale, cost and reliability reasoning: rough sizing, partitioning, replication, and making edits durable before acknowledging them - The product view: what users see during a conflict, while offline or in an outage, and how sync quality would be measured ### Follow-up Questions - A laptop that was offline for a week reconnects with edits to a file that a colleague also changed online. What should each person see? - A document shared across a whole company is opened by thousands of people at once. What breaks first, and how would you handle it? - Version history grows storage with every edit. How would you decide how much history to keep?