Complete System-Design Transcripts

Five answers to the same prompt

The most revealing moment in a system-design interview is often a small one. The candidate names three stores; the interviewer asks, “If they disagree, which one wins?” A fluent answer suddenly has to become a design.

That pressure is hard to study in an architecture diagram. A transcript keeps the sequence intact: what the candidate volunteered, what the interviewer had to extract, and whether a new constraint changed the model or merely changed the vocabulary.

The five rounds in this chapter begin with the same prompt:

Design a collaborative document editor for teams.

Users can create documents, edit at the same time, see collaborators' changes,
comment, and recover previous versions. The system is used by businesses, so
reliability, permissions, audit history, and migration matter.

Assume a 45-minute senior round. The interviewer expects the candidate to lead and will press on collaboration semantics, permissions, and reliability. Offline editing, rich media, billing, and machine-learning suggestions are out of scope unless the candidate brings them in and spends time defending the choice.

Read each exchange once without grading it. On a second pass, mark the first place the candidate commits to an answer for each of these questions:

• What is the authoritative history of a document?
• How are concurrent edits ordered, merged, acknowledged, and replayed?
• What state is durable, derived, ephemeral, or auditable?
• What happens when a user loses permission while connected?
• What is allowed to degrade when the real-time path or durable write path fails?

If no commitment arrives, note who had to rescue the discussion. The contrast between the transcripts lies less in the components than in when—and whether—these questions acquire definite answers.

Five rounds, one design

Transcript 1: strong senior performance

Interviewer: “Design a collaborative document editor for teams.”

Candidate: “I want to frame the product before naming components. I assume teams can create documents, invite collaborators, edit concurrently in a browser, comment, and restore previous versions. Because this is for businesses, the design has to preserve edit intent, permissions, audit history, and recovery. Should I treat this as near-real-time online collaboration, with offline editing out of scope?”

Interviewer: “Yes. Near-real-time browser collaboration. Offline can be out of scope.”

Candidate: “Good. Then I will optimize for online collaboration with durable history. I will spend a few minutes on requirements and scale, define the write path and data model, then deep dive on concurrent edits and reliability. I will keep estimates light unless you want more detail.”

The opening removes a major branch. Offline-first collaboration would change client storage, conflict surfacing, synchronization, and support costs.

Interviewer: “Keep estimates light.”

Candidate: “Functional requirements: create and open documents, edit with other users, show presence, comment, manage permissions, view history, and restore versions. Non-functional requirements: p95 edit propagation should feel comfortably below a second for active collaborators, acknowledged edits must not be lost, permission checks must be correct, and audit history must be reconstructable. Presence can be best effort. Document contents and audit cannot be.”

Interviewer: “What scale assumption would you use?”

Candidate: “I would size by active documents, active editors per document, and operation rate, not just total registered users. For a baseline, assume many documents have one editor, some have a handful, and rare hot documents have dozens of editors or thousands of viewers. That means the common case should be simple, while hot-document fan-out and per-document ordering are the stress points.”

Interviewer: “What APIs matter?”

Candidate: “For HTTP: create document, get metadata, get snapshot, list versions, add comment, change permissions, and restore version. For collaboration, a persistent channel is better: subscribe to a document and submit an edit operation. A submitted operation includes document_id, session_id, client_operation_id, base_revision, actor, and an operation payload. The server response is either rejected, already applied, or committed at a new revision.”

Interviewer: “How do you model storage?”

Candidate: “The authoritative history is an append-only operation log per document. A document snapshot is derived state for fast load. Metadata tracks title, owner, tenant, latest revision, snapshot pointer, and lifecycle status. Comments are separate records with stable anchors into document content. Presence is ephemeral in memory or short-lived storage. Audit events are durable and include actor, operation id, permission context, and timestamps.”

The ownership is now explicit: history is authoritative, snapshots accelerate loads, and presence may disappear without damaging the document.

Interviewer: “What happens when two users edit the same sentence?”

Candidate: “The key choice is the collaboration algorithm. I would use a server-ordered operation model with operational transform or a CRDT-like representation, depending on document semantics. I should be precise about the contract rather than hiding behind the acronym: the server accepts operations against a base revision, checks permission, transforms or merges against operations already committed after that base revision, assigns the next revision, appends durably, and broadcasts the committed operation.”

Interviewer: “Why server-ordered instead of fully peer-to-peer or active-active regional writes?”

Candidate: “Because the stated product is online, business-facing, permission-sensitive, and audit-heavy. A server sequencer gives one committed order per document, makes restore and replay easier, and gives us a single place to reject edits after permission revocation. The cost is a per-document coordination point. I would accept that for this product, then scale by partitioning documents across collaboration servers.”

Interviewer: “Draw the high-level architecture.”

Candidate: “Clients connect through an edge gateway that authenticates and upgrades to a WebSocket or similar stream. A collaboration service owns active sessions for documents assigned to it. It checks a cached permission view with invalidation events, applies operations through the collaboration engine, appends committed operations to a durable log, and publishes committed operations to subscribers. A metadata service owns document records and permissions. Snapshot workers compact operation logs into snapshots. Comment, audit, search indexing, and export are downstream consumers of committed operations or metadata changes.”

Interviewer: “What is the write path for an edit?”

Candidate: “Client sends operation with base revision and idempotency key. The collaboration service validates session and permission, loads recent committed operations after the base revision if needed, transforms or merges the operation, appends it to the durable log, then acknowledges it with the committed revision. Broadcast comes after commit. If broadcast fails, connected clients can recover from the log. If append fails, the operation is not acknowledged.”

Interviewer: “How do you handle thousands of viewers and dozens of editors on one document?”

Candidate: “Viewers can be fanned out through pub/sub or edge fan-out because they do not affect ordering. Editors still go through the per-document sequencer. If a document becomes very hot, we can reduce presence fidelity, batch outbound operations, separate viewers from editors, and apply backpressure. Splitting the document by section is possible only if product semantics allow independent ordering domains. I would not claim arbitrary horizontal scaling for a single shared text stream.”

The answer refuses a tempting false scale claim. The design can partition documents; it cannot make one ordered text stream arbitrarily parallel.

Interviewer: “What about permissions?”

Candidate: “Permission is checked when opening and before accepting each write-like operation. Long-lived sessions need revocation. A permission change emits an invalidation event consumed by collaboration servers. If access is revoked, the server closes the stream or downgrades it to read-only and rejects later edits. Durable operation records include actor identity and enough permission context for audit, but the current permission system remains the source of truth for future access.”

Interviewer: “How do clients recover after a collaboration service crash?”

Candidate: “Clients reconnect with document id, session id, and last seen committed revision. The new owner checks authorization, loads the latest snapshot if needed, reads operations after the client’s revision, and resumes the stream. Client retries use the same client_operation_id; the server dedupes within document and session scope. Acknowledged operations are safe because ack follows durable append.”

Interviewer: “How would you migrate from an existing single-user editor?”

Candidate: “I would use an expand-migrate-contract path. First add the operation log and snapshot model beside existing document saves. For existing documents, create a baseline snapshot at revision zero. Then route a small cohort through collaborative sessions while legacy reads still load snapshots. During the overlap, version restore, export, audit, and search must work from the new model before we remove the old save path. The risky part is not adding a table; it is proving replay, restore, and permission behavior before broad rollout.”

Interviewer: “Summarize the design.”

Candidate: “The design uses a durable operation log as the source of truth, snapshots as derived load accelerators, server-ordered per-document collaboration sessions, WebSocket fan-out after commit, permission enforcement at open and write, idempotent operation submission, and reconnect from last seen revision. The main trade-off is accepting a per-document ordering bottleneck to gain auditability, restore semantics, and permission correctness. The main risks are hot documents, transform correctness, permission invalidation latency, and snapshot lag; I would operate those with edit-ack latency, commit failure rate, reconnect catch-up failures, invalidation failures, and replay tests.”

Why the answer holds together

The candidate makes one consequential choice—one committed order per document—and lets it govern the rest of the round. The operation log owns history; acknowledgment follows durable append; retries deduplicate against that history; reconnect replays it; permission revocation reaches the active collaboration owner; migration must prove that replay and restore work. The answer is senior because its later details are consequences of an earlier decision, not because it contains more components.

Transcript 2: shallow but polished performance

Interviewer: “Design a collaborative document editor for teams.”

Candidate: “Sure. I would use React on the frontend, a Node backend, Redis for caching, Kafka for events, Postgres for metadata, and S3 for documents. The backend would be split into document, collaboration, comment, user, and notification services.”

Interviewer: “What should the product guarantee?”

Candidate: “It should be fast, scalable, and reliable. Users should be able to edit together and see updates in real time.”

Interviewer: “How do concurrent edits work?”

Candidate: “Users connect over WebSockets. When one user types, the server broadcasts the change to the others. Redis pub/sub can distribute updates across servers.”

Interviewer: “What if two users edit the same sentence at the same time?”

Candidate: “We can merge changes. There are libraries for this, and if there is a conflict we can use last-write-wins.”

Interviewer: “Which one would you choose?”

Candidate: “Probably merge, because collaborative tools need merging. The exact algorithm depends on implementation details.”

This sounds reasonable until the interviewer asks for a decision. “Depends on implementation” hides the central design choice.

Interviewer: “What is the source of truth?”

Candidate: “Postgres stores document metadata, Kafka stores events, and S3 stores snapshots. Redis caches active documents for speed.”

Interviewer: “If those disagree, which one wins?”

Candidate: “Kafka should have the events, but Postgres has the latest document. We can reconcile them with background jobs.”

Interviewer: “When do you acknowledge an edit?”

Candidate: “Once the server receives it and sends it to the other clients. We can persist it asynchronously for performance.”

Interviewer: “What if the server crashes after broadcasting but before persistence?”

Candidate: “Kubernetes restarts it. The client can resend changes, and Kafka can help avoid loss.”

Interviewer: “How do permissions work?”

Candidate: “There is an auth service. APIs check JWTs and roles. For WebSockets, the token is checked when the connection opens.”

Interviewer: “If access is revoked while the user is editing?”

Candidate: “The next request should fail. We can make WebSockets reconnect periodically so the token refreshes.”

Interviewer: “Summarize.”

Candidate: “The design uses WebSockets, Redis, Kafka, Postgres, and S3. It scales horizontally with microservices and supports collaboration, comments, permissions, and version history.”

Why polished is not the same as senior

The vocabulary is good, but the commitments are missing. The candidate never fixes:

• the authoritative order of edits;
• the relation between event log, current document, and snapshot;
• whether an acknowledged edit is durable;
• how duplicate retries are detected;
• how permission revocation reaches long-lived sessions;
• how restore and audit are reconstructed;
• what the system does when real-time delivery succeeds but durable persistence fails.

Every sentence is locally plausible. The answer fails when two of those sentences meet. “Which one wins?” exposes the missing model; “when do you acknowledge?” exposes the missing promise. Fluency has allowed the candidate to move without deciding.

Transcript 3: architecture-heavy and product-blind

Interviewer: “Design a collaborative document editor for teams.”

Candidate: “I would design a globally distributed active-active system. Each region has API gateways, collaboration workers, Kafka, Cassandra, Redis, and a service mesh. Clients connect to the nearest region for low latency. Data replicates asynchronously across regions.”

Interviewer: “Before architecture, what user requirements matter?”

Candidate: “The main requirements are availability, low latency, and global scale. We want the system to work from anywhere.”

Interviewer: “What does collaboration mean for editing?”

Candidate: “Users send edits to their local region. Regions replicate events. If two regions receive edits at the same time, the system resolves conflicts eventually. We can use vector clocks or CRDTs.”

Interviewer: “If two teammates edit the same paragraph from different regions, what do they see?”

Candidate: “They may briefly see different states, but the document converges. That is the standard distributed-systems trade-off.”

“Standard trade-off” is not a product answer. The prompt is about business documents, not an abstract replication exercise.

Interviewer: “Can a user restore an earlier version and audit who changed what?”

Candidate: “Yes. Every region emits events to Kafka. The audit service can consume the event streams and build history.”

Interviewer: “What is the global order for restore?”

Candidate: “There may not be a single global order at first, but we can sort by timestamp and merge events.”

Interviewer: “What if clocks disagree?”

Candidate: “We can use logical clocks. Cassandra handles distributed writes, and Kafka keeps order within partitions.”

Interviewer: “How do permissions work across regions?”

Candidate: “Permissions are cached regionally for speed and replicated asynchronously. Tokens have TTLs.”

Interviewer: “If an employee is removed from a confidential document, can they keep editing until the TTL expires?”

Candidate: “There is always propagation delay in a global system. That is the trade-off for availability.”

Interviewer: “Is that acceptable for this business product?”

Candidate: “Maybe for some documents. We can shorten the TTL or add a central permission check for sensitive documents.”

Interviewer: “Would that change your architecture?”

Candidate: “It adds a dependency, but the global active-active architecture still works. We can tune the consistency by document type.”

Interviewer: “Summarize.”

Candidate: “It is a global active-active architecture with regional gateways, collaboration services, Kafka, Cassandra, Redis, and asynchronous replication. It gives low latency and high availability, with eventual consistency across regions.”

The product judgment failure

This candidate may know distributed systems. The failure is one of sequence: topology arrives before the product promise. Each follow-up asks for a user-visible semantic—edit order, restore, audit, revocation—and each answer defends active-active writes. The design never earns its defining choice.

The design could become senior if the candidate paused and reframed:

I over-optimized for global latency before validating the document guarantees.
For business documents with audit and revocation requirements, I would start with
a primary region per document or tenant and treat cross-region routing as a
latency and disaster-recovery problem, not as unconstrained active-active writes.

Multi-region systems are not the error. Refusing to reconsider the consistency model after the product contradicts it is the error.

Transcript 4: flawed start with strong recovery

Interviewer: “Design a collaborative document editor for teams.”

Candidate: “I would store each document as a row in a database. When users edit, the client sends the full document to the server, the server saves it, and WebSockets broadcast the latest version to other users.”

Interviewer: “What happens if two users type at the same time?”

Candidate: “The later save could overwrite the earlier one. That is a bad fit for collaborative editing. Let me correct the model rather than patching it.”

Interviewer: “Go ahead.”

Candidate: “The collaboration primitive should be an edit operation, not a full-document save. Each operation has an id, actor, base revision, and payload. The server orders operations per document, transforms or merges concurrent operations, appends the committed operation to a log, and broadcasts the committed result.”

The recovery works because the candidate replaces the flawed write model. A lock or retry around full-document saves would preserve the mistake.

Interviewer: “What changes in storage?”

Candidate: “The document row becomes a snapshot for fast load, not the source of every edit. The source of truth is the operation log. Snapshots can be rebuilt by replay. Comments, permissions, and audit events stay separate because they have different query and retention needs.”

Interviewer: “How do you prevent duplicate operations after retries?”

Candidate: “Use an idempotency key scoped to document id, session id, and client operation id. If the client times out and retries, the server returns the committed revision for that operation instead of applying it twice.”

Interviewer: “When do you acknowledge an edit?”

Candidate: “After durable append. Broadcast can lag or fail because clients can catch up from the log. If we acknowledge before durability, we risk telling the user an edit was saved when it was not.”

Interviewer: “What did your first design miss?”

Candidate: “It treated a collaborative editor like a single-user form. That lost edit intent, made audit coarse, made version restore unreliable, and gave no safe retry behavior. The corrected design preserves a replayable sequence of user intent.”

Interviewer: “Continue with permissions.”

Candidate: “On open, the server checks whether the user can read the document. On edit or comment, it checks write or comment permission. Because the connection is long-lived, permission changes need invalidation events to active collaboration servers. If access is revoked, the server rejects subsequent operations and closes or downgrades the session.”

Interviewer: “And reliability?”

Candidate: “The invariant is acknowledged edits are not lost or applied twice. If the collaboration service crashes, clients reconnect with the last seen revision and catch up from the log. If snapshot generation lags, new sessions load an older snapshot plus subsequent operations. Alerts should track edit commit failures, edit-ack latency, reconnect catch-up failures, snapshot lag, and permission invalidation failures.”

Interviewer: “Summarize the corrected design.”

Candidate: “I started with full-document saves, which is wrong for concurrent editing. The corrected design uses operations as the write unit, a durable operation log as history, snapshots as derived state, idempotency keys for retries, ack after durable append, permission invalidation for live sessions, and reconnect from last seen revision. The important correction is shifting from storing state alone to storing the ordered intent that created state.”

What recovery proves

The opening still costs time and confidence. What rescues the answer is not the admission itself but the propagation: changing the write unit changes storage, idempotency, acknowledgment, permission checks, recovery, and the final summary.

When you make a wrong first move, recover in this order:

1. State the defect in product terms.
2. Replace the invariant, not just the component.
3. Re-run the affected write path.
4. Name what the correction changes in reliability and audit.
5. Summarize the revised design without apologizing for the rest of the round.

Transcript 5: deep reliability pressure

Interviewer: “Assume we already chose a server-ordered operation-log model. I want to spend the rest of the round on reliability. What can go wrong?”

Candidate: “The main failure modes are collaboration service crash, durable-log append failure, duplicate client retries, WebSocket disconnects, snapshot lag, permission invalidation delay, hot-document overload, backup failure, and bugs in the transform logic. I would anchor reliability around one invariant: an acknowledged edit must not be lost, reordered incorrectly, or applied twice.”

Interviewer: “Pick the first failure.”

Candidate: “Durable-log append failure. If the log is unavailable for a document, the collaboration service must stop acknowledging edits for that document. It can keep read-only viewing and presence if those paths still work, but it should show degraded status and keep local client edits clearly uncommitted. Accepting edits into an in-memory buffer as if they are saved would violate the product promise.”

Interviewer: “What if the client has already sent the operation and times out?”

Candidate: “The client retries with the same operation id. The server checks the idempotency record or operation log. If committed, return the committed revision. If not committed and the log is healthy, attempt again. If the log is unhealthy, reject with retryable failure and do not claim success.”

Interviewer: “How do reconnects work after a server crash?”

Candidate: “A client reconnects with document id, user identity, session id, and last seen committed revision. The new collaboration owner verifies permission, fetches missed operations after that revision, and streams them. If the gap is too large because log segments were compacted, the server sends a snapshot at revision N plus operations after N. If authorization fails, it does not provide catch-up data.”

Interviewer: “How do you know snapshots match the log?”

Candidate: “Snapshots are derived, so they need validation. Each snapshot stores document id, base revision, creation job id, and checksum. Background jobs sample documents, replay operations to the snapshot revision, compare checksums, and flag mismatches. Restore and export paths should prefer replayable history over trusting a stale snapshot blindly.”

Interviewer: “How do you detect transform bugs before they corrupt many documents?”

Candidate: “Use deterministic replay suites with real anonymized operation shapes where allowed, property tests for transform invariants, shadow validation for new transform code, canary rollout by tenant or document cohort, and snapshot-vs-replay comparison after rollout. A transform bug is not just an availability issue; it can corrupt user data. The rollout gate should stop on divergence, not only on latency or crash rate.”

The candidate distinguishes service health from data correctness. A transform service can be healthy while it corrupts documents.

Interviewer: “What alerts page someone?”

Candidate: “Page on user-impacting or data-risk signals: durable append failures, edit-ack failure rate, p95 edit acknowledgment latency above the product target, reconnect catch-up failure rate, permission invalidation failures for protected documents, and replay or checksum divergence. Snapshot lag may page only if it threatens recovery or load objectives; otherwise it can be a ticket. Queue depth alone is not enough without age or user impact.”

Interviewer: “What is the disaster recovery story?”

Candidate: “The operation log, metadata, comments, permissions, and snapshots all need backups, but the recovery objective is defined by acknowledged edits. Losing acknowledged operations violates the invariant. I would test restore by rebuilding sampled documents from backup logs and comparing with snapshots. For regional failure, the simplest model is document or tenant primary region with failover after ensuring the operation log is replicated to the recovery region. During uncertain failover, degrade writes rather than split-brain the document.”

Interviewer: “How do you handle permission revocation during an outage?”

Candidate: “If the permission system or invalidation stream is down, the safe behavior depends on data sensitivity. For business documents, I would avoid accepting new edits when the server cannot verify write permission. Existing read streams might continue for a short bounded period only if the product and tenant policy allow it. For protected documents, fail closed. This is a product and security policy, so I would make it explicit rather than bury it in a cache TTL.”

Interviewer: “Summarize reliability.”

Candidate: “The reliability design protects acknowledged edits and authorized access. Ack follows durable append, retries are idempotent, reconnect catches up from last seen revision, snapshots are derived and validated against replay, transform changes use replay tests and canaries, alerts page on commit, latency, catch-up, invalidation, and divergence, and disaster recovery avoids split-brain by failing over document ownership deliberately. When durability or authorization is uncertain, the system degrades to read-only or retryable failure instead of pretending edits are saved.”

Why this deep dive scores senior

Every answer returns to two product promises: saved edits remain saved, and unauthorized edits are not accepted. That focus gives the candidate a basis for deciding when to reject writes, when read-only degradation is honest, when lag deserves a ticket, and when divergence must stop a rollout. Reliability is judgment about failure, not a tour of backups and dashboards.

Listen across the transcripts

The comparison is easiest to hear when the same moment in each round sits next to the others. Use the table as an index back into the dialogue, not as a set of phrases to memorize.

Put one answer under pressure

Record your own version of the round, then introduce one constraint after the architecture has settled. Choose a constraint that forces a decision rather than another component:

• offline editing adds a local operation queue, synchronization protocol, conflict surfacing, and a new user-visible meaning for “saved”;
• ten thousand viewers force viewer fan-out away from editor ordering, with backpressure and an honest single-document limit;
• legal hold constrains deletion and restore while adding retention, access evidence, and export controls;
• immediate permission revocation requires live-session invalidation and may require bypassing stale authorization caches for writes;
• a transform bug calls for replay tests, canarying, divergence detection, quarantine, repair, and snapshot rebuild;
• migration from full-document saves requires a baseline snapshot, compatible reads, cohort rollout, restore validation, and a deliberate end to the old contract.

On playback, do not assign yourself a single score. Find the first answer that commits the design. Identify the source of truth, the acknowledgment point, and the first trade-off with a user-visible cost. Then find the follow-up that should have changed the model. If it did not, replace the answer and carry the correction through the affected paths.

For example:

I treated the current document as the source of truth, but collaborative editing
needs operation-level history; I would shift to a durable operation log with
snapshots as derived load accelerators.

The useful unit of review is the commitment: what did the candidate promise, what did that promise force elsewhere, and did it survive pressure? Components matter because they carry those commitments. Without them, even an impressive architecture remains unscorable.

The previous chapter, Driving the Conversation, showed how to keep a changing route visible. The casebook begins next with Infrastructure Primitives, where small interfaces put the same discipline under sharper constraints.