AI & Technical question

How would you implement the sync feature of Google Drive app or Google Docs? How would you design the DB for G-drive?

Practice this question out loud. An AI interviewer asks it, follows up like a real interviewer would, and scores your answer. Type or speak.

What this question tests

System design thinking applied to a product problem: sync architecture and data modeling trade-offs.

Clarify scope: syncing file edits across multiple devices with offline support and conflict resolution, not just upload/download.
Describe the sync approach: chunk files into blocks, hash each block, and only transfer changed blocks to minimize bandwidth.
Explain conflict handling: last-write-wins for simple cases, versioned branches or merge prompts for simultaneous edits like Docs.
Sketch the DB schema: files table, versions table with block references, and a device-sync-state table tracking each client's last synced version.
Discuss trade-offs: consistency versus latency, and how much local caching to keep for fast offline access.
Define success metrics: sync latency, conflict rate, and failed sync rate.

Distinguishes file-level sync (Drive) from operational-transform or CRDT-based sync (Docs), since Docs needs real-time multi-user merging.
Explains block-level diffing with a concrete example, e.g. only re-uploading a changed paragraph instead of the whole file.
Proposes a versions table with a foreign key to a device_sync_state table so partial or failed syncs can resume.
Flags conflict resolution as the hardest part and proposes a merge UI rather than silent overwrite.

Describing only the upload path and ignoring offline edits and conflict resolution.
Proposing a schema with no versioning, which cannot support undo or collaborative editing.

How would you handle two users editing the same paragraph offline at the same time?
How would you scale this for a file with millions of small edits?