Evaluation of Google Docs’ Design

Evaluate the editor at three boundaries: a local edit becoming an accepted revision, accepted operations reaching other replicas, and a new document authority taking over after failure. These transitions determine what “responsive,” “saved,” and “consistent” mean.

Requirements compliance

This lesson will focus on how our design meets the non-functional requirements.

Consistency

A correct OT protocol can transform edits within an accepted revision order; a suitable CRDT can converge under its merge and delivery rules. Neither name alone promises linearizability. Store revision and operation metadata explicitly: ordering by timestamps in a time series database does not resolve concurrent editing semantics.

Replication must preserve the chosen protocol’s requirements. Gossip can disseminate state or operations, but does not by itself establish one authoritative edit order. In the centralized design, define durable acceptance and fence old owners during failover. If the service permits independent CRDT updates, define how those updates are retained and synchronized.