Many Writers, One Object
In one line: every previous chapter had many readers and few writers, or many writers to different things. This is the first where many people write to the same object at the same time, and that changes what correctness means.
The problem
Document collaboration: multiple users can edit a document simultaneously, and a large number of users can view it.
Conflict resolution: the system pushes edits to all collaborators and resolves concurrent editing conflicts.
Every previous chapter avoided this problem; this one cannot
Look at how the module's systems have handled writes:
| System | Write pattern | Conflicts |
|---|---|---|
| Twitter, Instagram | Each user writes their own posts | None — no shared object |
| Uber | Each driver writes their own location | None |
| Each message has one author | None | |
| Web crawler | Partitioned so one worker owns a host | Avoided by partitioning |
| Typeahead | All writes go offline in batch | Avoided by serialization |
| Google Docs | 20 users writing one document | Unavoidable |
Every one of those either partitioned the write space so no two writers collided, or serialized writes through a single point. This chapter can do neither, because the requirement is explicitly that people edit the same paragraph at the same time.
That makes it the first genuinely concurrent-mutation problem in the course, and the consequence is that correctness stops being obvious:
There is no single right answer. If two people insert different text at the same position, both edits are legitimate. The system must produce an answer that everyone agrees on — not the answer, because there isn't one.
Users have local copies that diverge. The design states it: "users modify a local copy, so their view may diverge from the server state until updates are pushed." Every editor is briefly working on a different document.
The goal is convergence, not prevention. You cannot stop the conflict; you can only guarantee that everyone ends up in the same place afterwards.
When many writers share one mutable object, the design goal shifts from preventing conflicts to guaranteeing that conflicting states converge. That is the whole subject of Lessons 4 to 7.
Why locking is the wrong answer
The design asks this directly, and the answer is worth having early:
Locks require us to segment documents into small sections where users can lock a portion and edit it... However, this leads to poor user experience. Two users may want to add characters to the same section, but their operations may not necessarily conflict.
A lock is a good choice for services like Google Sheets, because the document is divided into equal-sized small cells, and only one user can edit a specific cell.
The Sheets comparison is the sharpest thing in the chapter
This is a genuinely good observation and it generalizes.
Locking requires a natural unit to lock. A spreadsheet has one: a cell is a well-defined, small, independently-meaningful region, and two people editing different cells genuinely do not interact. So Sheets can lock per cell and nobody notices.
A prose document has no such unit. What would you lock — a character? a word? a paragraph? Any choice is wrong:
Lock a character -> lock traffic exceeds edit traffic Lock a paragraph -> two people typing in one paragraph is COMMON, not exceptional
And the deeper point the design makes: two edits in the same region often do not actually conflict. Alice typing at the start of a sentence and Bob at the end are not competing for anything — a lock would serialize operations that were independent.
Locking is viable when the data has a natural granularity and contention within it is rare. Spreadsheets satisfy both; prose satisfies neither.
That is why this chapter needs OT or CRDTs at all. They are what you use when you cannot lock, and the reason you cannot lock is a property of the data model rather than of the scale.
What the chapter covers
| Sub-problem | Where |
|---|---|
| Why concurrent edits break — commutativity and idempotency | Lesson 4 |
| Operational transformation — rewriting indexes | Lesson 5 |
| CRDTs — unique identities and fractional positions | Lesson 6 |
| Which to choose, and the consistency contradiction | Lesson 7 |
| The surrounding architecture — queues, stores, WebSockets | Lesson 3 |
Two things to watch for as you read
Lessons 2 and 8 cover these in full; both are worth knowing in advance.
The estimation never computes the number that matters. It calculates storage and view bandwidth carefully, then sizes servers from daily active users treated as requests per second — 1,250 servers. The real load is edit operations, where one keystroke must be broadcast to up to twenty collaborators, and that figure appears nowhere.
The chapter says CRDTs give eventual consistency and then claims strong consistency using "OTs or CRDTs." Those cannot both be true, and the difference is not a detail — it is what the two techniques exist to trade against each other. Lesson 7 works through it.
This is what makes the problem unusual. Almost every other system in the course reduces contention by partitioning so that two users rarely touch the same thing. Here they touch the same thing by definition, so the answer has to be a merge rule rather than a routing rule.
Key takeaway
This is the first genuinely concurrent-mutation problem in the course: every earlier system either partitioned writes so no two writers collided, or serialized them through one point, and this one can do neither because the requirement is that people edit the same paragraph simultaneously. So correctness changes shape — there is no single right answer when two legitimate edits collide, and the goal becomes convergence rather than prevention. Locking is viable when data has a natural granularity and contention within it is rare — a spreadsheet cell qualifies, prose does not — which is precisely why this chapter needs OT or CRDTs, for a reason rooted in the data model rather than in scale.
Next: requirements and the estimation's missing number.