Dropbox / File Sync — Delta Sync + Dedup (WebSocket + CDN)

The delta sync approach represents the production-grade file sync architecture used by Dropbox, Google Drive, and OneDrive at scale. It builds on block-level chunking (V1) by adding three key optimizations: binary delta uploads, WebSocket push notifications, and CDN-accelerated downloads.

Binary delta sync is the most significant optimization. Even with 4MB block-level chunking, a small edit to a block still requires re-uploading the full 4MB. Delta sync computes a binary diff (using rsync-style rolling hash) between the old and new versions of a changed block, uploading only the changed bytes. For a typical text edit (100 bytes changed in a 4MB block), the delta is approximately 200 bytes — a 20,000x reduction from uploading the full block. Dropbox implemented this optimization in 2012 and reported bandwidth savings exceeding 95% for typical document editing workflows.

The delta sync protocol works as follows: (1) Client detects file change and splits into 4MB blocks with SHA-256 hashes. (2) Client compares new hashes with cached previous version to identify changed blocks. (3) For each changed block, client computes rolling-hash delta between old and new block versions. (4) Client uploads only the deltas to ChunkService. (5) ChunkService retrieves the base block from BlockStore (S3), applies the delta to reconstruct the new block, verifies SHA-256 integrity, and stores the new block. This adds one S3 read per delta upload but saves massive bandwidth.

WebSocket push replaces Kafka-based polling for sync notifications. Each connected device maintains a persistent WebSocket connection to NotificationService. When a file_changed event is published to SyncStream (Kafka), NotificationService pushes it to all connected devices for that user within 200ms. This provides sub-second sync awareness versus the 5-second polling delay in V0 or the variable Kafka consumer lag in V1. At 100M connected devices, NotificationService requires approximately 20 pods handling 5M connections each.

CDN-accelerated downloads serve content-addressed blocks from CloudFront edge caches. Since blocks are immutable (the SHA-256 hash never changes), they can be cached indefinitely at edge locations. For shared files (company documents, open-source project assets), CDN hit rate exceeds 60%, dramatically reducing both download latency (sub-10ms from edge versus 20ms+ from S3) and S3 egress costs.

The architecture separates upload and download into independent paths with their own load balancers and service pools. ChunkService handles the CPU-intensive upload path (delta reconstruction, SHA-256 verification). DownloadService handles the I/O-intensive download path (metadata lookup, pre-signed URL generation). This separation allows each path to scale independently based on its resource requirements.

Garbage collection uses a 72-hour grace period (extended from V1's 24 hours) to handle the longer tail of large delta uploads. GCWorker also manages version history cleanup — deleting file versions older than 30 days to control MetadataDB growth.

Interviewers at senior levels expect candidates to explain the delta sync protocol, discuss content-addressed block caching at CDN edge nodes, reason about WebSocket connection management at scale, analyze the trade-off between delta reconstruction overhead and bandwidth savings, and design the garbage collection strategy for sharded metadata.

The delta sync architecture uses eleven components organized into five layers: traffic entry (Client, ApiGateway), upload path (UploadLB, ChunkService), download path (DownloadLB, DownloadService, CDN), notification path (NotificationService consuming from SyncStream), data stores (MetadataDB, BlockStore), and async processing (SyncStream/Kafka, GCWorker).

The upload path handles file changes with delta optimization. Client detects a file change, splits into 4MB blocks, computes SHA-256 hashes, and compares with the cached previous version. For changed blocks, the client computes a binary delta (rsync rolling hash) between old and new block versions. The upload-init request sends all new hashes and delta sizes to ChunkService via ApiGateway and UploadLB. ChunkService checks MetadataDB for existing blocks (dedup check) and returns only the missing hashes. The client then uploads deltas for changed blocks — typically 1-10% of full block size. ChunkService retrieves the base block from BlockStore, applies the delta to reconstruct the new block, verifies SHA-256 integrity, and stores the reconstructed block in BlockStore. On finalize, ChunkService updates MetadataDB (sharded by user_id across 64 partitions) and publishes a file_changed event to SyncStream. 15 ChunkService pods handle the CPU-intensive delta reconstruction.

The download path serves file content with CDN acceleration. DownloadService (10 pods) receives requests via ApiGateway and DownloadLB, resolves file paths to block hash lists from MetadataDB, and generates pre-signed S3 URLs or CDN URLs for each block. The client downloads only blocks not in its local cache. CloudFront CDN edge caches serve popular blocks with sub-10ms latency — content-addressed blocks are immutable and cacheable indefinitely, achieving 60%+ hit rate for shared content.

The notification path provides sub-second sync awareness. NotificationService (20 pods) maintains persistent WebSocket connections with all connected devices. It consumes file_changed events from SyncStream (Kafka) and pushes them to the appropriate user's WebSocket connections. Notifications arrive within 200ms of the Kafka publish, compared to 5-second polling in V0. At 100M connected devices, NotificationService manages approximately 5M connections per pod.

MetadataDB (PostgreSQL) is sharded by user_id across 64 partitions. Each shard handles approximately 11M users at 700M total users. Sharding by user_id co-locates all of a user's file operations on the same shard, avoiding cross-shard queries. The blocks table is a global table (not sharded) since block dedup is cross-user.

BlockStore (S3) uses SHA-256 content hash as the S3 key. Blocks are immutable once written — never updated, only created and eventually deleted by GCWorker. This immutability enables aggressive CDN caching and eliminates cache invalidation complexity.

GCWorker (15 workers) consumes file_changed events from SyncStream, manages block reference counts in MetadataDB, and deletes orphaned blocks from BlockStore after a 72-hour grace period. Also handles version history cleanup (deleting versions older than 30 days).