SysPadExamples › Design Google Drive

Design Google Drive

A Block Server chunks/compresses/encrypts files into Block Storage, a Metadata DB tracks file/block/version relationships separately, a Notification Service syncs other clients on change, and a scheduled job tiers cold blocks to archival storage.

Splitting block storage from metadata, change notification as its own async path, and cold-tiering as a scheduled background job.

Client (Sync Agent) Users DNS Route 53 API Servers API Gateway Block Server Lambda Block Storage S3 Cold Backup Glacier Metadata DB DynamoDB Metadata Cache ElastiCache Notification Queue SQS Notification Service Lambda Cold-Tier Schedule EB Scheduler

How it works

Block Server
Splits a file into blocks, then compresses and encrypts each one. Only changed blocks are uploaded on a sync, which is what makes edits to a large file cheap.
Metadata DB
Tracks the file → block → version relationships separately from the blocks themselves, so a sync can diff versions and list blocks without touching object storage.
Metadata Cache
Clients poll for changes constantly, so the hot metadata (latest version per file) is cached to keep those checks off the metadata DB.
Notification Queue
A change is queued here so the sync fan-out to a user’s other devices happens asynchronously, never blocking the upload that caused it.

Request flows

Sync a file (upload)

  1. Client (Sync Agent)
  2. DNS
  3. API Servers
  4. Block Server
  5. Block Storage
  6. Metadata DB
  7. Notification Queue

Check for changes

  1. Client (Sync Agent)
  2. DNS
  3. API Servers
  4. Metadata Cache
  5. Metadata DB

Sync other devices

  1. Notification Queue
  2. Notification Service

Tier cold blocks

  1. Cold-Tier Schedule
  2. Block Storage
  3. Cold Backup

Other interview practice

Open this architecture in SysPad · All examples