Two users edit the same document at 9:03 AM.
No locking. No coordination. Just two clients writing to the same record.

Both changes hit your server 300ms apart. One lands first. The other overwrites it.

User A's work is gone. They never get an error. They just… lose their change.

This is the multi-writer conflict problem. Every collaborative system hits it eventually. Your choices:

A) Last-Write-Wins (LWW) — highest timestamp takes the record. Loser's change disappears silently.
B) Vector Clocks — track causality per replica, detect conflicting versions, surface them to the application for resolution.
C) CRDTs (Conflict-free Replicated Data Types) — data structures that mathematically merge concurrent writes without coordination.
D) Operational Transformation (OT) — transform each operation relative to concurrent operations before applying, keeping intent intact.

Google Docs, Figma, Notion, and DynamoDB all took different bets here.

One of these scales to millions of concurrent writers. One of them works fine until it silently corrupts your data. Two require fundamentally different data models.

Pick one — A, B, C, or D — and tell me why. I'll drop the full breakdown in the comments (including which one Google Docs actually uses and why they almost got it wrong).

30DaysOfSystemDesign #SystemDesign #DistributedSystems #BackendEngineering