We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
This idea carries a full system design question on its own. Each walks through the full answer.
System Design Masterclass · Web Content Delivery
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Web Content Delivery
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
Two users edit the same document on two different devices. Both are offline. They come back online at the same time and push their changes. Now what?
This is the sync problem. It sounds simple until you try to solve it for real. Google spent years building Operational Transform for Docs. Figma built a custom CRDT for their multiplayer canvas. Notion rewrote their sync engine twice before shipping a version that handled conflicts without losing data.
The cost of getting sync wrong is real: Evernote lost user notes due to sync conflicts in 2014, causing a public trust crisis. Dropbox built an entire "conflicted copy" mechanism because their sync engine could not always merge file changes automatically. Every app that lets users work on multiple devices or collaborate with others must pick a sync strategy, and each one has trade-offs that are impossible to avoid.
The comparison above covers four fundamentally different approaches to keeping client and server in sync. Polling is the simplest but wastes bandwidth. WebSockets give you real-time bidirectional communication but require persistent connections that complicate load balancing. Server-Sent Events are simpler than WebSockets for one-way pushes. CRDTs are the nuclear option: mathematically guaranteed conflict-free merges, but with higher memory overhead and a steep learning curve.
Most applications use a combination. Slack uses WebSockets for real-time message delivery, polling as a fallback, and server-side conflict resolution for message edits. Linear uses WebSockets for presence and live updates, plus a sync engine based on fractional indexing for issue ordering.