Requirements and Estimation

In one line: the estimation computes the read side accurately and then sizes the fleet from something else entirely — while the quantity that actually drives this system never appears.

Requirements

Non-functional: latency (users collaborate across regions) · consistency (resolve conflicts so everyone sees the same state) · availability · scalability.

Twenty concurrent editors is the assumption that shapes everything

Buried in the estimation assumptions: maximum 20 concurrent editors per document.

That bound is doing more work than any other number in the chapter, and it works in the design's favour twice.

It bounds the conflict rate. Conflict resolution complexity grows with the number of concurrent writers. Twenty is small enough that a centralized ordering service — which Lesson 8's evaluation describes — can serialize operations without becoming a bottleneck.

It bounds the fan-out. Every operation must reach every other editor, so one keystroke becomes at most nineteen outbound messages. Unbounded, that would be the Twitter celebrity problem; bounded at twenty, push to everyone is always affordable.

That is the same shape as that building block's group size limits: a hard cap converts an unbounded distribution problem into a bounded one. And as there, the cap is a systems decision wearing product clothing.

Storage

80M documents/day x 100 KB text            =  8.0 TB
30% with images   x 800 KB                 = 19.2 TB
 2% with videos   x 3 MB                   =  4.8 TB
                                             --------
                                             32.0 TB/day

All figures reproduce exactly.

History is a functional requirement and is excluded from storage

Note: We omit historical data storage requirements for brevity.

That is a large omission, because History is a stated functional requirement and Lesson 3 gives it a dedicated time-series database.

Consider what edit history means in a system where every keystroke is a versioned operation:

A 100 KB document, typed once   = ~100,000 characters
Each operation stored with site ID, position, value, timestamp ~ 50 bytes
                                  ------------------------------------
History for ONE document        ~ 5 MB

Roughly fifty times the document itself. And that is for a document typed once, with no editing, no deletions, no revisions — real documents are written, rewritten, and edited over months.

So the honest storage picture inverts:

The mitigations are the ones any versioned system uses — snapshot periodically and discard intervening operations, compact runs of adjacent keystrokes into a single insert, and tier old history to cold storage. The design's own follow-up question asks about the trade-offs of storing history indefinitely and never answers it.

When operations are finer-grained than the objects they modify, the operation log outgrows the data. That is true of every event-sourced system, and here the ratio is roughly fifty to one.

Bandwidth

Incoming:  32 TB / 86,400 x 8              =  3 Gb/s

Views:     5 documents x 80M / 86,400      =  4,630 views/second
  text     4,630 x 100 KB x 8              =  3.70 Gb/s
  images   4,630 x 30% x 800 KB x 8        =  8.89 Gb/s
  video    4,630 x  2% x 3 MB x 8          =  2.22 Gb/s
                                              ----------
Outgoing                                      14.81 Gb/s
Total                                         ~18 Gb/s

Eighteen gigabits is small, and the read rate is the interesting figure

Against the module's other systems this is modest — Instagram moved 50 Tb/s, YouTube 12 Tb/s. Eighteen gigabits is a handful of machines.

But hold onto 4,630 views per second, because it is the only request rate the chapter computes, and the server section is about to ignore it.

Note also what the media split reveals: images are 60% of the storage and 60% of the egress despite appearing in only 30% of documents, while text — the thing the entire chapter is about — is a quarter of the bytes. That is why Lesson 3 puts media behind a CDN and blob storage, and why the interesting engineering is nonetheless entirely on the text path.

The bytes and the difficulty are in different places here, which is unusual — in most chapters the dominant data type is also the hard problem.

Servers

Considering our assumption that daily active users serve as a proxy for requests per second, we get 80 million requests per second.

80,000,000 / 64,000 = 1,250 -> "1.3 K servers"

The chapter computed a real request rate two sections earlier and then discarded it

The bandwidth section derived 4,630 document views per second. The server section substitutes 80 million.

Computed:  4,630 views/second      ->    0.07 servers
Asserted:  80,000,000 "per second" -> 1,250 servers
                                      -----------------
Factor:                               17,280x

This is the seventh appearance of the DAU-as-RPS convention in the module, and as always it treats a population as a rate — asserting that every one of 80 million daily users issues a request every second, all day.

But the correction here is more interesting than usual, because neither number is the right one. The reads are trivial; the system's actual load is something the chapter never mentions.

The number that matters: edit operations, fanned out twentyfold

A collaborative editor's request rate is driven by keystrokes, not by document loads — exactly as in the typeahead chapter, and with an amplifier the typeahead chapter did not have.

Every keystroke is an operation that must be:

1. sent to the server
2. ordered against concurrent operations
3. persisted to the history log
4. BROADCAST to up to 19 other editors

So one keystroke becomes roughly twenty network events. Sketch the scale:

Those are the figures that would size the WebSocket tier, the operations queue, and the ordering service — the three components Lesson 3 introduces — and none of them appears in the estimate.

Note the asymmetry with the bandwidth section: an edit is tiny in bytes and expensive in operations. A single character is a few dozen bytes, so the bandwidth stays small while the operation count is enormous. That is the trap the Uber and WhatsApp chapters both set: a small bandwidth figure conceals a large rate when the objects are tiny.

Size a collaborative editor by operations and their fan-out, not by document views.

The building blocks, and the one that is unusual

Databases, blob storage, CDN, load balancers, caching, queueing, and pub-sub.

The queueing system is the distinctive entry, and the design explains why: "Since concurrent edits cannot be processed instantly, a queue temporarily holds requests."

That is the conflict-resolution machinery appearing in the block list. Lesson 3 makes it concrete — the operations queue is where ordering happens — and Lesson 8 confirms it must be FIFO with strict ordering, because the order operations are applied in determines the final document.

A queue in this design is not a buffer for load smoothing; it is the serialization point that makes convergence possible.

Worth separating early: a document has at most a handful of simultaneous editors and can have an unbounded number of viewers. The hard problem is confined to the editor path, and treating readers the same way needlessly imposes its cost on the easy case.

Next: the components and the workflow.