Google Drive / Dropbox

We split files into 4 MB blocks and compute SHA-256 per chunk. We chose 4 MB (not 64 KB or 64 MB) because smaller chunks explode the index while larger chunks miss partial edits. A 1 GB file with 2 changed chunks transfers 8 MB, not 1 GB. Trade-off: CPU cost of hashing 256 chunks per GB.

We store each unique chunk once, keyed by SHA-256 hash. We chose reference counting (not mark-and-sweep GC) for deletion tracking because ref_count updates are O(1). Saves 40-60% of total storage. Trade-off: ref_count can drift on crashes, requiring weekly reconciliation.

We chose long polling (not WebSockets, not SSE) with cursor-based delta sync because long polling is stateless and firewall-friendly. Each device holds an open HTTP request for up to 60 seconds. Trade-off: up to 1 second latency versus WebSocket's near-instant push, but we eliminate connection affinity overhead.

We chose fork-and-surface (not LWW, not OT) because LWW silently discards edits and OT requires an always-online server that fails for binary files. We detect concurrent edits via version vectors and create a conflicted copy. Trade-off: users see occasional conflict files, but zero data loss.

We chose the tus protocol (not custom) because it is an open standard with battle-tested client libraries. PUT 4 MB chunks sequentially, server tracks byte offset in Redis. Trade-off: one extra HEAD request per retry, but maximum wasted transfer per drop is 4 MB instead of the full file.

We shard 100B file records across 16 MySQL shards by user_id hash (not file_id) because the dominant access pattern is user-scoped. Sharding by file_id would scatter every 'list my files' query across all 16 shards. Trade-off: cross-user queries (shared files) require scatter-gather, but these are 100x less frequent.

We separate metadata in MySQL from chunks in S3/GCS because metadata is 200B/row and read-heavy while chunks are 4 MB and write-heavy. We chose S3 (not HDFS, not local disk) for 11 nines durability with zero disk management. Trade-off: crash between S3 write and MySQL update creates orphaned chunks, cleaned by reconciliation.

We chose long polling (not WebSockets) for sync notifications because it is stateless, firewall-friendly, and needs no connection affinity. We fan out through Kafka partitioned by user_id. We rate-limit per-folder at 1/sec to prevent notification storms from viral shared folders. Trade-off: up to 1 second latency vs. WebSocket push.