Collaborative document editing (Google Docs)

It depends on the editing model. If every edit goes through a server, OT with a central sequencer is a proven choice: the server orders ops, transforms concurrent ones against each other, and the document stays compact. Google Docs works this way. If offline editing, multi-device sync or peer-to-peer matter a lot, I lean towards a CRDT such as Yjs or Automerge, because any replica can merge any set of ops in any order and still converge, with no central transform step. The cost is metadata: element IDs and tombstones grow, so I need compaction and snapshotting. In either case I still keep a server-side op log, because history, audit, permissions and recovery need one authoritative record.

While offline, the client applies edits locally and persists them in IndexedDB, along with the last revision the server acknowledged. On reconnect it first fetches all ops the server accepted after that revision. With OT, the client transforms its pending queue against those ops and sends them rebased on the current revision; with a CRDT, it simply exchanges missing updates using state vectors and both sides merge. The server treats replayed ops like any other: it checks the user still has edit permission, assigns revisions and appends them durably. Ops carry client IDs and sequence numbers so retries are idempotent. For very long offline sessions I may show the user a summary of what changed, but the merge itself is automatic.

The client applies the character to its local model immediately, so typing feels instant. It wraps the change in an operation with its base revision (OT) or a unique element ID (CRDT) and sends it over the existing WebSocket. The gateway forwards it to the session server that owns the document. That server checks the user's permission, transforms or merges the op against anything newer than its base, assigns the next revision, and appends it durably to the operation log. Only then does it acknowledge the sender. It publishes the op on the document's fan-out channel. Every gateway with clients on that document pushes it out, and each client transforms or merges it into local state. Presence updates travel separately and are never logged.

The rule is simple: no acknowledgement until the op is durable. The session server appends the op to a replicated, append-only log and waits for a quorum or synchronous replica to confirm before sending the ack. If the server crashes after the write but before the ack, the client retries with the same client ID and sequence number, and the server sees it is already logged and returns the existing revision. If it crashes before the write, the client still holds the op as pending and resends it. Snapshots are only an optimisation built from the log, never the source of truth. Backups, and checksums on snapshots, guard against corruption and operator mistakes.

Clients see the WebSocket drop and enter reconnect mode. They keep editing locally and queue unacknowledged ops. Ownership is held by a lease in a coordination service such as etcd or ZooKeeper. Once the lease expires, another server acquires it with a higher fencing token, loads the latest snapshot and replays the log tail to rebuild the exact state at the last durable revision. Clients reconnect through the gateway, which now routes to the new owner. Each client sends its last acknowledged revision, receives the missed ops, and resubmits pending ops with their original IDs so duplicates are ignored. Users usually notice only a brief 'reconnecting' indicator, and nothing acknowledged is lost because the log is the source of truth.

Permission is checked on every op at the session server, not only when the WebSocket opens. The ACL service publishes change events. The session server and gateway subscribe to them, invalidate any cached role and re-evaluate open sessions for that document. If a user is downgraded to viewer, their next edit op is rejected and the client switches to read-only. If access is removed entirely, the server closes the session and stops fan-out to that client. Cached roles carry a short TTL as a safety net in case an event is missed. Ops from an offline client are checked against the current role on reconnect, so stale permissions cannot be used to write later.

Each client session has a unique client ID and numbers its ops with a strictly increasing sequence. The pair (client_id, seq) is the idempotency key, and the log enforces it as unique per document. If an ack is lost and the client resends, the server finds the existing entry and returns the original revision instead of applying the op twice. The server also tracks the last applied seq per client. A gap shows that a message is missing, so the server asks for a resend rather than applying ops out of order. CRDTs are naturally tolerant of duplicates because element IDs are unique, but deduplicating at the log still saves storage and keeps the revision history clean.

I separate connection handling from document logic. Many stateless gateways hold the sockets; one session server owns the document and does ordering. Accepted ops are published once to a per-document channel, and each gateway subscribed to that channel fans out to its local clients, so the session server does not write to hundreds of sockets. Presence is the noisier stream, so I throttle cursor updates, batch them, and for very large audiences show only a subset of cursors. Clients can also batch keystrokes into small op groups. If a document has far more viewers than editors, viewers can subscribe to the fan-out without touching the session server. Ownership leases with epochs make failover safe.

A lease alone is not enough, because a server paused by a long GC or a network partition may not know its lease has expired. Each lease grant comes with a monotonically increasing fencing token. The operation log store accepts appends only when the writer's token is at least the highest token it has seen for that document, and it rejects older ones. A stale owner's writes then fail, and that server must drop its sessions. A conditional append also helps: write revision N+1 only if the current head is N. Together these make the log the arbiter, so even a brief split brain cannot produce two different op sequences with the same revision numbers.

I would use a documents table holding doc_id, owner, title, created time, the current head revision and the latest snapshot revision. The operation log is keyed by (doc_id, revision). Each row stores the op payload, author user ID, client ID, client sequence number, timestamp and op format version. A unique constraint on (doc_id, client_id, client_seq) gives idempotency. Snapshots are keyed by (doc_id, revision), and the serialised document goes in object storage with a checksum. ACLs live in their own service as (doc_id, principal, role). Comments are stored separately as (comment_id, doc_id, anchor, thread, author, resolved state). Partitioning everything by doc_id keeps a document's data together, which suits the single-owner model.

I would state my assumptions clearly and derive from them. Start with concurrently open documents and the average number of active editors per document. Then estimate ops per second per editor after client-side batching, since keystrokes are coalesced into small ops. Multiplying gives total op writes per second to the log, and multiplying again by average op size gives write bandwidth. Fan-out traffic is ops multiplied by recipients per document, so it grows with collaborators, not just writers. Presence traffic is often larger than edit traffic, which is why it is throttled. Storage is ops per day times op size, plus snapshots. Finally, concurrent WebSocket connections divided by safe connections per gateway node tells you how many gateways you need.

Every revision exists implicitly because the log is complete. To show revision R, load the nearest snapshot at or before R and replay ops up to R. Cost is bounded by the snapshot interval, so old revisions are as cheap to load as recent ones. For the history UI, users do not want every keystroke. I group ops into named or time-bucketed versions by author and session, and I store a lightweight diff summary so the list renders without replaying anything. Restoring an old version should not rewrite history. It appends new ops that move the document to that state, so the restore can itself be undone and no collaborator's work disappears.

Undo must be local. Pressing Ctrl+Z should undo my last change, not a colleague's. The client keeps a stack of its own ops. To undo one, it computes the inverse op, such as a delete for an insert, and then transforms that inverse against every op applied since, including remote ones, so it lands in the right place in today's document. The result is sent as a normal new op, so history stays append-only and other clients just see another edit. With CRDTs, undoing a delete means reviving the tombstoned elements, and undoing an insert means deleting those IDs. Redo is the same idea in reverse. Edge cases, such as undoing text someone else has since deleted, need sensible no-op behaviour.

Tombstones exist because a concurrent insert might reference a deleted element as its neighbour. They can only be removed safely once every replica has seen the deletion, a state called causal stability. With a central server, that becomes practical. The server tracks the minimum acknowledged version across all known replicas and garbage-collects tombstones older than that during compaction. The catch is long-offline clients: you cannot wait forever. A common policy is a horizon after which a stale client cannot merge directly. It must rebase its pending ops onto a fresh snapshot. Modern sequence CRDTs such as Yjs also compress runs of consecutive elements into blocks, which keeps metadata small even before garbage collection.

With a single-owner design, the document's session server lives in one region, ideally near most of its active editors, and ownership can move when usage shifts. Remote users pay a cross-region round trip for acknowledgements and for seeing others' edits. Their own typing stays instant because the client applies ops locally first, and they see colleagues' changes after the propagation delay. Gateways remain local to each user, so TLS and the WebSocket terminate nearby, while the op path rides the backbone to the owner. The log is replicated across regions for disaster recovery. Multi-master per document is possible with CRDTs, but it complicates ordering, permissions and revision numbers, so most production systems keep one owner.

A single owner gives a total order of ops for free. It assigns revision N+1, keeps the current state in memory and transforms against a known history, so OT stays simple and CRDT merging stays cheap. Permission checks, rate limits and snapshots all have one place to run. The costs are a scaling ceiling per document, extra latency for distant users, and a failover gap when the owner dies. These are acceptable because a single document's edit rate is human-bounded and small, and leases with fencing make failover safe. Multi-writer designs remove the hotspot but need consensus or full CRDT semantics everywhere, which is more complexity than most products need.

The classic design, from Jupiter and used by Google Wave, keeps at most one op in flight. While waiting for its ack, new local edits are composed into a single buffer op. When a remote op arrives, the client transforms it against both the in-flight and buffered ops before applying it, and also transforms those pending ops so they stay valid. When the ack arrives, the buffer becomes the next in-flight op. This keeps the server's transform simple, because each client op is based on a revision the server knows. It also batches naturally: fast typing during a slow round trip becomes one op, not dozens.

A comment is anchored to stable positions, not raw character offsets. With a CRDT, the start and end are element IDs, so inserts before them do not change the anchor. With OT, the anchor range is transformed through every op just like a cursor. When the anchored text is partly deleted, the range shrinks to whatever remains. If it is fully deleted, the comment becomes orphaned: it is kept in the thread list and shown as 'original text deleted' rather than silently removed. Undoing the deletion should restore the anchor, which CRDT tombstones make straightforward. The comment body, replies and resolution state live in a separate store, so comment edits do not bloat the document log.

A remote cursor is just a position, so it has to move with the text. In OT, each client transforms every cached remote cursor offset through incoming and local ops. In a CRDT, the cursor is expressed as an element ID plus a side, so it stays correct without transformation. Presence messages carry the sender's revision, so the receiver can transform a slightly stale cursor up to its own state, or drop it if it is too old. Updates are throttled and coalesced so only the latest position matters. Entries expire on a short TTL, which makes cursors from closed tabs disappear. Each cursor's colour and name come from the session roster, not from the op log.

Plain-text algorithms are not enough. Formatting should be stored as marks anchored to the start and end positions, not as per-character flags copied at write time. Each mark type needs a defined expansion rule. Bold usually grows to include text typed at its end, while a link usually does not. Concurrent conflicting marks, such as bold and unbold on overlapping ranges, need a deterministic winner, often decided by a Lamport timestamp. Every replica then resolves the conflict the same way. The Peritext work from Ink & Switch describes these issues for CRDTs. With OT, you define transform functions for format ops against inserts and deletes. Either way, I would fuzz-test formatting heavily because the edge cases are subtle.

A suggestion is an edit that is recorded but not yet accepted. I would represent it as ops tagged with a suggestion ID and author, so the text appears with strike-through or a highlight but is marked provisional in the model. Because they are real ops anchored to the same positions, suggestions move with concurrent edits exactly like normal text. The server allows commenter-role users to create only suggestion-tagged ops and rejects plain edits from them. Accepting a suggestion appends an op that clears the tag. Rejecting it appends ops that remove the inserted text and restore any deleted text. Both are logged, so history shows who proposed and who approved each change.

Replaying thousands of missed ops can be slower than sending fresh state, and in OT it also means transforming the client's pending queue against all of them. The server compares the gap with a threshold. Beyond it, the server sends the latest snapshot plus a short tail instead. The client keeps its unacknowledged local ops, rebuilds from the snapshot and then rebases or merges its queue on top. If tombstones before the client's version have been garbage-collected, a direct merge may no longer be possible. The client then computes a diff between its local text and its last known base and resubmits that diff as new ops. The user's work survives, even if fine-grained intent is slightly reduced.

The key user-facing SLI is op acknowledgement latency at p50 and p99, measured from client send to ack, because it reflects durability and server health. Next comes remote propagation latency: time from one user's ack to another user's render. I would track document load time split into snapshot fetch and tail replay, plus the average replay length, which tells me if compaction is falling behind. On reliability: reconnect rate, ops rejected, idempotent duplicates seen, and fencing rejections, which are a split-brain warning. Most important is a convergence check: clients periodically send a hash of their state at a revision, and any mismatch triggers an alert and a forced resync.

Unit tests are not enough, because bugs hide in rare interleavings. I use property-based fuzz testing. Spin up several simulated replicas, generate random inserts, deletes and format ops, deliver them in random orders with delays, duplicates and disconnects, then assert all replicas end with identical state. For OT, I also verify the transform properties directly on random op pairs. Failing cases are shrunk to minimal reproductions. In production, clients periodically report state hashes at known revisions, catching bugs the fuzzer missed. Chaos tests kill session servers mid-write and check that no acknowledged op disappears. Keeping the same core library on client and server ensures tests exercise the real code.

Viewers send no edit ops, so the challenge is fan-out, not merging. I separate viewer traffic from editor traffic. Editors stay on the owning session server's path. Viewers attach to a broadcast tier: the fan-out channel feeds relay nodes that push ops to many read-only connections. Each relay holds a recent op buffer, so a lagging viewer can catch up without touching the session server. Presence for viewers is aggregated into a count rather than individual cursors, which removes most of the traffic. Initial loads come from a cached snapshot. If ops arrive faster than viewers can render, relays can batch them or send periodic snapshots, because viewers do not need every intermediate state.

In transit, everything runs over TLS, including service-to-service links, with mutual TLS inside the cluster. At rest, the log, snapshots and comments are encrypted with keys from a KMS, often using per-tenant keys so an enterprise customer can revoke access. Access to raw data is audited and restricted to break-glass roles. End-to-end encryption is harder. Classic OT needs the server to read ops to transform them, so it conflicts with E2E. A CRDT design can work because the server only orders and relays ciphertext. You lose server-side features, though: search indexing, previews, snapshots built by the server, and permission checks based on content. That is a real trade-off to discuss with product.

The interval trades load speed against write and storage cost. Frequent snapshots mean short replays on open but more large writes. Rare snapshots mean long replays. I usually trigger on a mix of op count, accumulated bytes and time since the last snapshot, so busy and quiet documents are both handled. The compactor runs off the hot path. It builds the snapshot by replaying the log, stores it with its revision and a checksum, and only then updates the document's latest snapshot pointer. Older snapshots can be thinned out for history. To build trust, I periodically verify that a snapshot plus replay matches a fresh replay from an earlier snapshot.

I never trust the client. The session server validates every op against a schema: positions within bounds, known op types, sizes under limits, valid element IDs, and a supported format version. Invalid ops are rejected with an error that forces the client to resync from a snapshot, rather than being partly applied. Permissions are checked server-side for every op, including formatting and comment ops. Per-user and per-document rate limits stop floods. Text content is sanitised before rendering in other users' browsers to prevent XSS through pasted HTML or links. If a client keeps producing invalid ops, its session is closed and the event logged, because that usually means a bug or tampering.

A client on a poor mobile connection must not slow everyone else. Each gateway keeps a bounded outbound buffer per connection. Presence messages are dropped first when it fills, since only the latest cursor matters. Ops are never dropped silently: if the buffer overflows, the gateway closes or flags the connection, and the client resyncs from its last revision using the log or a snapshot. The session server publishes once to the channel and never waits for individual clients. Gateways can also coalesce several queued ops into one frame. Monitoring buffer depth and forced resyncs per connection shows network trouble before users complain.

A huge paste should not become one giant message that blocks the session. The server enforces a maximum op size and the client splits large inserts into chunks that share a paste ID, so they still undo as one action. Images and attachments go to object storage through a separate upload, and the document holds only a reference. For very large documents, the client loads incrementally: it fetches the snapshot structure and renders the visible portion first. Snapshots may be split by section so compaction does not rewrite everything. There are also hard per-document limits on size and ops per second per user, which protect shared infrastructure from abuse or runaway scripts.

Deleting a document is harder than deleting one row, because its content lives in the log, snapshots, search index, caches, backups and notification payloads. I would soft-delete first, moving the document to trash for a recovery window. A hard delete then removes log partitions, snapshots and comments, and sends deletion events through the change feed so search and other downstream systems purge their copies. Backups age out on a documented schedule. Crypto-shredding helps here: if each document or tenant has its own key, destroying the key makes residual copies unreadable. Retention policies and legal holds must override user deletion where the law requires, and the policy should be reviewed with legal counsel.

The log, or a CDC stream from it, publishes committed ops with doc ID and revision. An indexer consumes them, but re-indexing per keystroke is wasteful, so it debounces per document. After a quiet period, or every few minutes during active editing, it loads the current text and re-indexes the whole document at that revision. Storing the indexed revision lets it skip stale work and stay idempotent when it replays the feed. Search is eventually consistent, and users tolerate short delays. Permissions matter more than freshness: the index stores ACL metadata, results are filtered at query time against the current ACL, and ACL changes trigger prompt index updates.

Every op and snapshot carries a format version. Servers are deployed first and must read both old and new formats. During the transition, they can down-convert ops for old clients where possible, or ask clients that cannot understand a new feature to refresh. New op types ship behind a flag and are enabled only once nearly all active clients support them, which telemetry confirms. Old ops in the log are never rewritten. Replay code keeps every historical version so version history still works. Offline clients present a special case: on reconnect, they declare their version, and the server either accepts their ops through an upgrade path or requires a reload before they can submit.

1. AAs soon as it receives the op over the WebSocket
2. BAfter the op is durably appended to the operation logCorrect answer
3. CAfter every other client has applied the op
4. DAfter the next snapshot includes the op

Why: Acknowledging only after a durable log append is what guarantees an acknowledged edit is never lost. Waiting for other clients or snapshots adds latency without improving durability.

1. ATo rate-limit fast typists
2. BTo identify the user's role
3. CTo encrypt ops in transit
4. DTo let storage reject writes from a stale owner after the lease movesCorrect answer

Why: A paused or partitioned old owner may still try to write. A monotonically increasing token lets the log reject its writes, which prevents two different histories.

1. AThe client ID plus a per-client sequence numberCorrect answer
2. BThe document title
3. CThe op's text content
4. DThe server timestamp

Why: (client_id, seq) uniquely identifies an op from a session, so a resent op can be recognised and given its original revision instead of being applied twice.

1. AOther clients filter them out
2. BThe snapshot later removes them
3. CThe ops are accepted because the WebSocket is authenticated
4. DThe session server rejects them after checking the role on each opCorrect answer

Why: Authorisation must be enforced server-side for every op. The client can never be trusted to restrict itself.

1. APosition 2
2. BPosition 5
3. CPosition 6
4. DPosition 4Correct answer

Why: B removed one character before position 5, so A's insert must shift left by one, to position 4, to keep its intended place.

1. ABecause WebSockets cannot connect clients directly
2. BTo encrypt operations end to end
3. CTo compress operations before storage
4. DTo provide a single total order so transformations are applied consistentlyCorrect answer

Why: Many OT algorithms only guarantee convergence when there is one agreed order of operations, which a central sequencer provides. Without it, proving correct transformation for every concurrent combination is very hard.

1. AIt rejects concurrent writes
2. BIt is commutative, associative and idempotentCorrect answer
3. CIt uses wall-clock timestamps for every write
4. DIt requires a leader to approve merges

Why: A join that is commutative, associative and idempotent produces the same result whatever the order of merges and however often an update is redelivered, so all replicas converge.

1. ATP2 (convergence property 2)
2. BIdempotence
3. CCommutativity of snapshots
4. DTP1 (convergence property 1)Correct answer

Why: TP1 requires that two concurrent ops, each transformed against the other, lead to the same document state. TP2 deals with transforming against sequences and matters in decentralised OT.

1. ARead it from the search index
2. BAsk the client that made revision R
3. CReplay every op from revision 0 every time
4. DLoad the nearest snapshot at or before R and replay ops up to RCorrect answer

Why: Snapshots bound the replay length, so any revision loads in roughly constant time relative to the snapshot interval.

1. ATo support spell-check
2. BSo concurrent inserts that reference a deleted element can still be placed correctlyCorrect answer
3. CTo reduce memory use
4. DBecause databases cannot delete rows

Why: A concurrent insert may name a deleted character as its neighbour. Keeping the tombstone lets every replica resolve that position the same way.

1. AThey are composed into a buffer and sent after the ack arrivesCorrect answer
2. BThey are written directly into the snapshot
3. CThey are discarded
4. DThey are sent immediately, each with its own base revision

Why: Keeping one op in flight and buffering the rest means every op the server sees is based on a revision it knows, which keeps server transforms simple.

1. AReplicas that have received the same set of updates are in the same stateCorrect answer
2. BEdits are applied in wall-clock order
3. CA central server must approve every edit
4. DAll replicas are always identical at every instant

Why: Strong eventual consistency means convergence is deterministic once the same updates are delivered, regardless of order, with no conflict resolution rounds.

1. ARevert the whole document to the previous snapshot
2. BDelete the last entry from the operation log
3. CUndo the most recent op from any user
4. DUndo the user's own last op, transformed against later ops, sent as a new opCorrect answer

Why: Undoing others' work is confusing, and rewriting the log breaks history. Selective local undo, sent as a new transformed op, avoids both problems.

1. AFetch revision 104 from the server before applying 105Correct answer
2. BReload the whole page
3. CAssume 104 was empty
4. DApply 105 and ignore the gap

Why: Fan-out may be at-most-once. Revision numbers let clients detect gaps and fill them from the durable log so ops are applied in order.

1. AAutomatic merging of both histories
2. BA harmless duplicate snapshot
3. CSlower cursor updates only
4. DTwo different ops recorded with the same revision number, so clients divergeCorrect answer

Why: Both owners assign revisions independently, so the log and the clients can end up with conflicting histories. That breaks convergence and can lose acknowledged edits.

1. AThe CRDT server only needs to order and relay ops, while OT needs to read ops to transform themCorrect answer
2. BOT ops are always larger
3. CCRDTs forbid permissions
4. DCRDTs do not need encryption

Why: Server-side OT transforms require plaintext positions and content. Clients can merge CRDT ops themselves, so the server can relay ciphertext.

1. AWait until the user closes the tab
2. BPush an ACL change event that invalidates cached roles, with a short TTL as backupCorrect answer
3. CCheck permissions only at WebSocket connect
4. DRely on the client to refresh its role

Why: Event-driven invalidation applies revocation quickly, and the TTL bounds staleness if an event is missed.

1. AWritten into each document snapshot
2. BIn ephemeral in-memory state with a short TTL, broadcast to peersCorrect answer
3. CIn the comments database
4. DAppended to the durable operation log

Why: Presence changes constantly and has no long-term value, so it stays in memory with a TTL and may be lossy. Persisting it would bloat the op log and slow history replay.

1. AThe user's permission level
2. BThe document size
3. CThe wall-clock time of an edit
4. DWhether two events are concurrent rather than causally orderedCorrect answer

Why: Lamport timestamps give a total order consistent with causality but cannot reveal concurrency. Vector clocks can show that neither event happened before the other.

1. AIt removes the need for failover
2. BIt encrypts document IDs
3. CAdding or removing a server remaps only a small fraction of documentsCorrect answer
4. DIt guarantees equal CPU use on every server

Why: With consistent hashing, only keys near the changed node move, which limits disruption when the cluster changes.

1. AThey must be durable like edits
2. BOnly the latest position matters, and stale entries should vanish when users leaveCorrect answer
3. CBrowsers cannot send them faster
4. DThey are stored in version history

Why: Presence is ephemeral. Throttling cuts bandwidth, and a TTL clears cursors from closed tabs without explicit cleanup.

1. AIt is the only protocol that supports TLS
2. BIt gives a persistent full-duplex channel, so the server can push ops with low latencyCorrect answer
3. CIt stores ops offline
4. DIt removes the need for authentication

Why: A persistent bidirectional connection avoids polling delay and request overhead, which suits frequent small messages in both directions.

1. AReplay every missed op regardless of count
2. BDelete the client's pending ops
3. CReject the client permanently
4. DSend the latest snapshot plus a short tail, and let the client rebase or merge its pending opsCorrect answer

Why: A snapshot catches the client up cheaply while its unacknowledged local work is preserved and reapplied.

1. AFaster loads but more snapshot writes and storageCorrect answer
2. BWeaker durability of acknowledged edits
3. CLoss of version history
4. DSlower document loads but less storage

Why: Shorter intervals shorten replay on load at the cost of more frequent, larger snapshot writes.

1. AlocalStorage is unavailable over HTTPS
2. BIndexedDB encrypts data with the user's password
3. CIndexedDB syncs to the server automatically
4. DIndexedDB is asynchronous and handles larger structured data, while localStorage is synchronous and smallCorrect answer

Why: Long offline sessions can produce many ops. IndexedDB stores structured data with far higher limits and does not block the main thread.

1. AEach keystroke appears only after a cross-region round trip
2. BTheir own typing is instant, while acks and others' edits arrive with extra latencyCorrect answer
3. CTheir edits are rejected
4. DEdits are lost if latency is high

Why: Optimistic local application hides latency for one's own edits. Only server confirmation and remote propagation pay the distance.

1. A(timestamp) only
2. B(revision) global across all documents
3. C(user_id) only
4. D(doc_id, revision)Correct answer

Why: Partitioning by document and ordering by revision supports fast tail reads and conditional appends, and keeps a document's history together.

1. AThe pair of replica (site) ID and a per-replica counterCorrect answer
2. BThe character's current index
3. CThe user's email address
4. DA random 8-bit number

Why: Each replica increments its own counter, so (site_id, counter) is unique without coordination.

1. ASilently drop some ops
2. BDisconnect or flag the client so it resyncs from its last revisionCorrect answer
3. CGrow the buffer without limit
4. DBlock the session server until the client catches up

Why: Ops cannot be silently dropped, and one slow client must not stall others. A forced resync from the durable log restores correctness.

1. ANumber of comments per document
2. BAverage document title length
3. CCPU use of the compactor
4. Dp99 op acknowledgement latency and ack error rateCorrect answer

Why: The ack includes the durable write. Its latency and failure rate directly show the health of the save path users depend on.

1. ACopy a bold flag onto each character at write time only
2. BAs marks anchored to start and end positions, with defined expansion rulesCorrect answer
3. CAs a separate document per style
4. DAs HTML strings replaced wholesale

Why: Anchored marks with clear expansion and conflict rules, as in Peritext, give consistent results when text is inserted at or within the range.

1. AKnowing every replica has observed the deletion (causal stability)Correct answer
2. BThe user clicking save
3. CRunning a spell-check pass
4. DA fixed timer of one minute

Why: Removing a tombstone before all replicas have seen it can break the placement of concurrent inserts. Long-offline clients therefore need a cut-off and a rebase path.

1. ADelete all later comments
2. BTruncate the operation log back to that revision
3. CAppend new ops that move the document to the old stateCorrect answer
4. DOverwrite the latest snapshot only

Why: Appending keeps history immutable and auditable, and the restore itself can be undone. It also never destroys collaborators' later work.