280
Gbps uploading at the weekday-morning peak
Assume a billion commits a day, each adding 1 MB after dedup and compression. Bytes on that scale must bypass the application servers.
Where do the bytes go?
Bad: Through the API
One drop restarts a 50 GB upload from zero.
Good: Straight to a block store
4 MB blocks named by SHA-256, uploaded in parallel. Commit the list last.
Wi-Fi drops after 8,400 of 12,500 blocks. Start over?
No. Commit again, and the server lists the 4,100 still missing. There’s no upload session; the stored blocks are the progress record.
150 million devices are online at peak, and almost none has news.
The trick
A notifier says only “namespace 42 changed”. Devices pull journal rows after their cursor. Notifications are hints; the journal is the truth.
Asha edits on a flight, Ravi at the office. Same file.
Both began at revision 17, and Ravi’s commit made 18. Asha’s names stale parent 17, so hers becomes a conflicted copy.
Never lose an edit
- Every commit names the revision it edited
- Stale parent? Keep a conflicted copy
- Never let device clocks decide
- Three trees, remote, local and synced, show which side changed
Skip uploads anyone already stored. What could leak?
A skipped upload means “someone has this file”. Try every “Salary: ₹X” in an offer-letter template. So dedup across users only on the server.
5 EB
of user data, mostly never read again
Every 0.1× of storage overhead costs 500 PB of disk. Replicate fresh blocks; move cold ones to fragments across three regions.
Remember
Hashed blocks go straight to storage; a per-namespace journal orders every change. Devices wake on hints and pull after their cursor, and stale commits become conflicted copies.