Collaborative Editor — Interview Perspective

Push for a concrete target instead of accepting the word at face value: local edits apply instantly (optimistic), remote propagation targets a low, illustrative latency budget, and durability follows its own separately-defined boundary. See Non-Functional Requirements.

• How many simultaneous editors per document should this handle? — Tests whether the candidate distinguishes typical collaboration size (a handful of editors) from viewer-heavy documents (thousands of passive viewers) — these stress different parts of the system.
• Is offline editing required, or just tolerated? — Changes whether Offline Queue and reconnect/resync are core requirements or a stretch goal.
• Do viewers need live updates, or just editors? — Affects whether presence and broadcast fan-out need to scale to a large passive audience.
• Are comments, suggestions, and version history in scope? — These have different data semantics than plain text edits — see Comments & Suggestion Mode.
• What are the durability expectations if a server crashes mid-edit? — Forces the candidate to state a durability policy early rather than discovering the gap later.
• Is this a plain text editor or a structured rich-text document? — Changes whether Structured Document Model needs to be part of the answer at all.

Collaboration traffic is small, frequent, and bidirectional — polling adds latency and wastes work on that pattern, while a persistent socket keeps a cheap channel open for edits, acks, cursors, and heartbeats. See Polling vs WebSockets and WebSocket Session Lifecycle.

• What happens when a gateway dies? — Tests knowledge that gateways are stateless connection managers — clients reconnect to another gateway and resume from their last committed version, they don't lose document truth.
• Where does connection state actually live? — Probes whether the candidate keeps document truth out of the gateway entirely.
• How do you scale to millions of connections? — Tests horizontal gateway scaling and stateless design, not a single monolithic socket server.
• How do you handle a slow consumer? — See Slow Consumer in Failure & Scale Scenarios — bounded queues, coalesce presence first, never silently drop a committed edit.
• What happens during a reconnection storm? — Tests admission control, backoff/jitter, and prioritizing the edit path over presence during recovery.

Every operation carries a stable opId; the authoritative path deduplicates by opId before applying anything, so a retried submission is recognized and not reapplied. See Operation Ordering & Idempotency.

• Why do we need opId specifically, rather than relying on the transport? — Transport may redeliver or retry; opId-based dedupe is what makes at-least-once delivery safe to build on.
• Why do operations carry a baseVersion? — It tells the server what state the client believed was current, which is what the transform/merge step reconciles against.
• How do you detect reordered or missing client operations? — A per-client clientSeq complements opId — gaps or repeats in clientSeq reveal reordering or loss without implying a global clock.
• Do we need global ordering across all documents? — No — ordering only needs to be authoritative within one document; unrelated documents don't need coordinated ordering.

Whole-document or blind-position writes let one user's edit silently overwrite another's, or apply against stale positions and corrupt text — the system needs a reconciliation step, not just a save. See Conflict Resolution.

• Explain Operational Transform without using mathematics. — Looking for: server finds what changed since the client's base version, transforms the incoming operation against that, assigns the next version, broadcasts the result. See Operational Transform Mechanics.
• What history does OT actually need to do this? — It needs the operations accepted since the client's base revision — if that's been compacted away, the server falls back to snapshot-based rebase. See OT History Retention.
• When might CRDT be preferable to OT? — Offline-heavy or more peer-to-peer-leaning designs, at the cost of different metadata and compaction trade-offs — not a strictly better choice. See OT vs CRDT.
• What complexity does CRDT introduce that OT avoids? — Accumulated identifiers, tombstones, and causal metadata that need careful, replica-safe garbage collection. See CRDT Metadata & Garbage Collection.
• Does CRDT eliminate the need for a backend? — No — durability, auth, presence, and networking are still needed regardless of which convergence strategy is chosen.

Only after the operation has been recorded per the configured durability policy — a lightweight transport ack may arrive earlier, but the "committed" status means durable, not just received. See Operation Durability & Acknowledgements.

• What if the owner crashes right after applying the edit in memory but before persisting it? — This is exactly the failure the durable-ack boundary prevents from being user-visible — see Lost Operations in Failure & Scale Scenarios.
• How do you guarantee an acknowledged edit is not lost? — By never sending the committed ack until the durability policy's boundary — durable log append or replicated write — is actually satisfied.
• What is the role of the operation log? — It's the durable, replayable record of accepted operations that recovery and materialization both depend on.
• Are the Document Store and the operation/version history updated as one atomic transaction? — Usually not — recovery instead relies on the operation log as source of truth, idempotent materialization, and version markers, not a distributed transaction. See Document Storage and the Durability Boundary.

One owner per document gives the system a single place to assign authoritative versions and serialize accepted operations, which keeps convergence reasoning local instead of requiring cross-server coordination on every edit. See Document Owner Routing.

• How are documents assigned to servers? — A Shard Router maps a stable routing key to an owning server, maintaining an ownership directory gateways can resolve against.
• What happens when the owner dies? — See Document Owner Failover — a new owner is established with a higher epoch, recovers from snapshot plus log tail, and clients reroute.
• How do you move a hot document to different capacity? — A planned handoff drains in-flight operations and transfers the epoch cleanly, unlike an unplanned crash.
• How do you prevent two owners from both accepting writes during failover? — This is the core question — expects fencing/epochs: the durable write path rejects any write tagged with a stale epoch. See Document Owner Lease & Fencing and Split-Brain Document Ownership.
• Do unrelated documents need coordinated ordering with each other? — No — ordering is scoped per document; there is no need for a single global order across the whole platform.

Presence is ephemeral, best-effort, and non-authoritative — fusing it into the correctness-critical edit path would waste authoritative capacity on noisy signals and risk making document correctness depend on something that's allowed to be stale. See Presence & Cursor Fan-Out.

• What happens if the Presence Service fails? — Text editing continues correctly; presence degrades gracefully or hides rather than showing confidently stale state — see Presence Service Failure.
• How do cursors scale on a document with 10,000 viewers? — Not every viewer needs every cursor — sampling, coalescing, and capping rendered cursors keep this from scaling linearly.
• Do you persist cursor history? — No — presence is ephemeral by design; it is not treated like durable document history.
• How do you handle a user with multiple tabs open on the same document? — Presence keys on session/client identity, not just user ID, so multiple tabs don't collapse into one shared presence entry.

Snapshots make bootstrap and restore fast; the operation log preserves full detail and supports OT transform and audit needs. The hybrid bounds both storage cost and replay cost. See Snapshot & Operation Log.

• How often do you snapshot? — A cadence choice — by operation count, time, or semantic event — with no single universal number; trade speed of restore against storage cost.
• When can old operations be deleted? — Only once restore/history, OT transform-history, offline-retention, and audit needs no longer require them — see Snapshot Compaction & Retention.
• How does restore work while other users are actively connected? — Restore is a new mutation, not time travel — it verifies permission, creates a new authoritative version through the normal collaboration path, and rebases connected clients onto it.
• What if a snapshot is corrupted or inconsistent with the log? — See Operation Log / Snapshot Divergence — fall back to the last known-good snapshot and replay the verified log.

The client keeps applying edits locally and queues them with stable operation IDs and a known base version — typing never blocks on network availability. See Offline Reconnect Protocol.

• How does reconnect actually work? — Walk the handshake: authenticate, recheck permission, report last acked version and queued ops, receive missing operations or a snapshot, transform/merge queued edits, dedupe idempotently, resume live.
• What if the document changed significantly while offline? — A large gap triggers a snapshot-based rebase instead of incremental replay.
• What if the OT history needed to transform the client's queued edits was already compacted away? — See Offline Client Returns After History Compaction — snapshot rebase, not unbounded replay.
• What if the user's edit permission was revoked while they were offline? — The server rechecks current permission during reconnect and must not blindly replay queued writes if authorization no longer allows it.

At the authoritative mutation path, on every write — not only when the socket first connects. See Authorization in Live Collaboration.

• Is checking access only at WebSocket connect time sufficient? — No — permission can change mid-session (revocation, workspace removal, link revoked); connect-time-only checks miss all of these.
• What happens after a live permission revocation? — See Permission Revoked During Active Editing — stop accepting writes, stop protected subscriptions, don't silently replay unauthorized offline edits.
• How do you prevent a malformed or malicious client from corrupting a document? — Validate every operation at the trust boundary — range, size, schema, base version — before it can influence authoritative state. See Bad Client Sends Malformed Operations.

Could be either, and they need different fixes — many concurrent editors stress write serialization, while thousands of passive viewers stress broadcast fan-out even at low edit rates. See Hot-Document Fan-Out.

• How do you support thousands of simultaneous viewers on one document? — Hierarchical fan-out, gateway-local subscription groups, and coalesced presence, rather than a flat broadcast to every subscriber individually.
• Can you shard a single document across multiple owners? — Not casually — splitting the authoritative write path reintroduces the exact coordination problem fencing exists to prevent; see Whole-Document vs Block-Level Synchronization.
• What changes for a very large document? — Snapshot serialization cost, transform window size, client memory/rendering, and bootstrap size all grow — see Large-Document Partitioning.
• How do you move ownership of a hot document safely? — A planned handoff with a clean epoch transition, not an abrupt reassignment — see Document Owner Lease & Fencing.

In a home/authoritative region for that document, with gateways distributed globally to terminate nearby client connections — keeping ordering and fencing localized rather than distributed across regions. See Multi-Region Collaboration.

• What if collaborators are on opposite continents from the home region? — They incur real network latency on their edit round trip — an accepted, explicit trade-off of this baseline, discussed in Single-Region Owner vs Multi-Region Writers.
• Would you ever allow active writers in several regions for the same document? — Possible, but substantially harder — requires cross-region coordination or consensus per operation unless the consistency model changes; treat it as an advanced alternative, not the default.
• What happens if the owner's home region fails entirely? — See Regional Failure — promote a fenced owner in a recovery region from replicated durable history, and be honest about the RPO/RTO trade-off.

The ack was sent before the operation was actually durable — the ack boundary must mean durably committed, not just accepted in memory. See Lost Operations.

Fencing epochs resolve it: the durable path rejects the stale owner's writes, the router refreshes ownership, and affected clients resync. See Split-Brain Document Ownership.

Detect the version gap and fetch the missing operation or a fresh snapshot rather than assuming pub/sub redelivery will fix it on its own. See Pub/Sub Broadcast Loss or Delay.

No, as long as version-gap detection and resync exist — pub/sub is a distribution mechanism, not the source of truth. See Pub/Sub Broadcast Loss or Delay.

Fall back to the last verified snapshot, replay the verified log forward, and rebuild materialized state — never trust a snapshot that fails its own integrity check. See Operation Log / Snapshot Divergence.

It almost certainly exceeds the retained operation history, so the server sends a current snapshot and the client rebases its queued edits against it rather than replaying an unbounded log. See Offline Client Returns After History Compaction.

Validation at the trust boundary rejects the operation before it ever reaches the transform/merge step, and the client can be rate-limited or disconnected if it persists. See Bad Client Sends Malformed Operations.

Not for live editing, which continues normally — but snapshot age and log length should be alerting, because reconnect and restore cost keeps growing the longer it stays down. See Snapshot/Compaction Worker Failure.

Almost certainly the fan-out/broadcast path, not the write path, since edit volume may stay low while distribution volume explodes — mitigate with hierarchical fan-out and coalesced presence rather than scaling the write path. See Document Hotspots and Hot-Document Fan-Out.