STANDARDwalkthrough

Sync Protocol

3 of 8
3 related
How does Dropbox make a file appear on a laptop within one second of saving it on a phone? The sync protocol combines three mechanisms.
When any file changes, the server pushes a lightweight change event down that connection. We chose long polling (not WebSockets) because it is stateless and firewall-friendly, requiring no persistent connection state on the server.
First, long polling: each device holds an open HTTP connection to the notification service.
Trade-off: long polling introduces up to 1 second of latency compared to WebSocket push, but eliminates the overhead of managing millions of persistent connections. Second, cursor-based delta sync: the client maintains a cursor (an opaque token representing its last-known state).
On each sync, it sends the cursor and receives only the changes since that point, not the full file list. Third, version vectors: each file carries a vector of (device_id, version_number) pairs.
When two devices edit the same file, the server compares version vectors to determine if the changes are causally ordered or concurrent. Dropbox processes over 1 billion sync events per day using this protocol.
What if the interviewer asks: 'Why not SSE (Server-Sent Events)?' SSE is unidirectional and simpler than WebSockets, but it holds a persistent TCP connection per device, the same operational burden we want to avoid.
Why it matters in interviews
Interviewers want us to compare long polling versus WebSockets for sync and explain why cursor-based deltas beat full-state sync at scale. Describing version vectors for conflict detection separates strong answers from average ones.
Related concepts