--- title: "37/60 Days System Design Questions" url: https://daily.dev/posts/37-60-days-system-design-questions-1uvzcb6zo source_url: https://daily.dev/posts/37-60-days-system-design-questions-1uvzcb6zo type: freeform source: "Joud Awad" author: "Joud Awad" published: 2026-06-12T16:49:07.635Z updated: 2026-06-12T16:49:35.232Z tags: ["career", "distributed-systems"] reading_time: 2 upvotes: 57 comments: 14 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # 37/60 Days System Design Questions **[Joud Awad](https://daily.dev/sources/iac4jsbu0lv8wbsc85fsh)** · [@joudawad](https://daily.dev/joudawad) · 2 min read · 57 upvotes · 14 comments ## Summary A system design challenge exploring the multi-writer conflict problem in collaborative applications. Four approaches are presented: Last-Write-Wins (LWW), Vector Clocks, CRDTs, and Operational Transformation (OT). Real-world systems like Google Docs, Figma, Notion, and DynamoDB each chose different strategies, with trade-offs around scalability, data integrity, and complexity. Readers are prompted to pick an approach and justify it, with a full breakdown promised in the comments. ## Content 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). Drop your answer 👇 _#30DaysOfSystemDesign #SystemDesign #DistributedSystems #BackendEngineering_ ## Community discussion Top comments from developers on daily.dev. **@joudawad** · 10 upvotes > **Answer: C — CRDTs** _(but the real answer depends on your conflict model — full breakdown below)_ > > > **C — CRDTs wins at scale** > > > CRDTs are data structures designed so any two replicas can always be merged — mathematically, without coordination. The key insight: if operations are commutative, associative, and idempotent, conflicts structurally _can't exist_. > > > Examples: > > > • **G-Counter**: only increments. Merge = take max per replica. Always converges. > > • **LWW-Element-Set**: union of adds + removes with timestamps. > > • **RGA / YATA (sequence CRDTs)**: each character gets a unique ID,... **@joudawad** · 5 upvotes > **D — Operational Transformation (OT) ⚠️ impressive but hard** > > > OT was Google Docs' original approach. When two operations arrive concurrently, you transform each one relative to the other before applying it. User A inserts at position 5, User B deletes at position 3 simultaneously — OT adjusts A's insert position to account for B's delete. Intent preserved. > > > That's why Google Docs felt magical in 2009. > > > But OT is operationally brutal. The transformation functions are notoriously hard to get right — the original OT papers had bugs. Every new operation type adds transformation pairs that... **@joudawad** · 4 upvotes > **B — Vector Clocks ⚠️ honest but incomplete** > > > Vector clocks track causality. Each write carries a version vector — one counter per replica. When two writes have no causal relationship (neither "happened before" the other), you know you have a conflict. Both versions surface to the application layer, which resolves them. > > > Amazon's internal Dynamo used this. It's correct and transparent. The problem: conflict resolution is now your job. You write merge logic for every data type. For shopping carts it's manageable (union the items). For arbitrary documents? It breaks down fast. > > > Vector... **@joudawad** · 3 upvotes > **A — Last-Write-Wins (LWW) ❌ dangerous** > > > Simple. Brutally simple. Highest timestamp wins. The loser's change vanishes — no error, no notification, just gone. > > > Cassandra defaults to this. For append-only workloads (metrics, event logs, telemetry) it's totally fine. For anything a human edited? It's silent data loss with a timestamp attached. The treacherous part: users never get an error. Their work just stops being there. **@lakshyam03** · 2 upvotes > How do these strategies handle if some users are editing/deleting the same part (the exact line and characters) simultaneously? How does the system handle ties? --- Tags: [#career](https://daily.dev/tags/career), [#distributed-systems](https://daily.dev/tags/distributed-systems) [View this post on daily.dev](https://daily.dev/posts/37-60-days-system-design-questions-1uvzcb6zo)