Realtime Collaborative SDLC

Candidate · clear top-down answerI see two promises. Drafts should feel instant and keep working offline. Published versions must be fixed, reviewed, and safe for other systems to use. I would design those as separate paths.

Why this mattersThis gives the interviewer a map before any boxes appear, and it makes the system's most important trust decision explicit.

Candidate · clear top-down answerVersion one supports structured requirements, comments, suggestions, offline edits, and publishing a fixed revision. People may edit; agents may only suggest. We will not build free-form design tools or automatic code changes yet.

Why this mattersA narrow first release keeps the design realistic. It also shows which tempting features can wait without weakening the core product.

Candidate · clear top-down answerThe peak is 8,000 small edit operations each second, or about 2.8 MB/s. If that peak lasted all day, the raw edit log would be roughly 240 GB/day before copies and indexes. The bigger storage risk is keeping every keystroke forever. I would keep recent edits for fast replay, combine older ones into snapshots, and keep published versions permanently. The calculator deliberately shows the worst case so we can size retention safely.

Why this mattersThe calculation is not about perfect forecasting. It identifies the part most likely to run out of capacity or delay users.

Candidate · clear top-down answerThe main records are document, block, edit operation, snapshot, suggestion, comment, approval, and published revision. Blocks get stable IDs so comments and moves keep pointing to the right thing. We read a room by document ID and sequence, reconnect from a client's last sequence, and publish by exact snapshot hash. Presence and cursor positions are temporary and do not belong in the permanent truth.

Why this mattersA small set of records is easier to reason about. Exact versions keep later changes from silently rewriting an earlier decision.

Candidate · clear top-down answerA conflict-free replicated data type, or CRDT, is a merge method that lets offline edits meet later without losing either side. I would use it for draft text and ordering, but not for publishing, permissions, approvals, or billing.

Why this mattersThe merge tool solves concurrent draft edits, not business authority. Keeping publish and approval transactional prevents “it merged” from being mistaken for “it is valid.”

Candidate · clear top-down answerThe client saves an edit locally, sends it to a nearby realtime server, and receives an acknowledgement only after the edit reaches a durable log. Other users see it through the live room. Background workers build snapshots and run document checks. Publishing follows a separate path: validate one snapshot, its references, and its approvals in a database transaction, then create a fixed revision for downstream systems.

Why this mattersTracing one real request proves the boxes connect. It also exposes where we acknowledge success and where a retry may begin.

Candidate · clear top-down answerText merging is not enough for structured documents. Each edit says what it means: move this block, change this field, or add this link. Moving a block and editing its text can merge, but deleting a required block while another user links to it creates a business conflict. We preserve both edits, show the conflict, and block publishing until a person resolves it. Automatic convergence does not mean the document is semantically valid.

Why this mattersThe deep dive starts only after the basic path is clear. Use one concrete example, then state the speed-versus-correctness choice.

Candidate · clear top-down answerComments point to a stable block plus positions that move with the text. If the block is deleted, the comment becomes orphaned but is not lost. Suggestions are small edit sets, so people can preview and accept them safely.

Why this mattersAnchors need stable identity plus a clear orphan state. Silently attaching a comment to nearby text would preserve the UI while changing its meaning.

Candidate · clear top-down answerDraft edits may arrive more than once and a little out of order; stable edit IDs make repeats harmless. Publishing is stricter: it checks the exact content hash and approvals in one transaction so only the reviewed version can ship.

Why this mattersUse immediate agreement only for decisions that cannot be ambiguous. Let rebuildable views catch up and always show their freshness.

Candidate · clear top-down answerAn offline agent returns a suggestion based on an old version, never a full document replacement. Stable block IDs let us apply independent edits. Anything that targets deleted or changed blocks becomes a visible conflict for a person.

Why this mattersA failure answer should name the uncertain state first. Then explain how the system learns the truth before it repeats an action.

Candidate · clear top-down answerFor a very busy document, assign the room to one ordered stream, combine tiny updates into frames, and cap each user's buffer. A slow client gets a fresh snapshot plus missing edits instead of forcing the server to hold unlimited history in memory. Reconnects use randomized delay, and room ownership moves with a numbered lease so two servers cannot both accept writes after failover.

Why this mattersBusy tenants and large jobs need limits. Reserved capacity keeps one customer or one import from delaying everyone else's live work.

Candidate · clear top-down answerApprovals belong to an exact content hash. If an agent changes a required block, the old approval becomes stale. Publishing either writes exactly the reviewed content or fails and asks the user to review again.

Why this mattersAn approval covers exact bytes, not a moving document name. The hash check turns a subtle race into a safe, visible request to review again.

Candidate · clear top-down answerCheck permission when a user joins, reconnects, publishes, or exports. Every database, cache, room, and log key includes the customer ID. Agent tokens are short-lived and limited to one project, document, and action. Document text is untrusted data, never an instruction to a tool, so an agent cannot gain permission from text someone typed into the document.

Why this mattersSecurity belongs in keys, tokens, workers, and logs. It is not a single box added to the diagram at the end.

Candidate · clear top-down answerMeasure edit acknowledgement time, peer update time, reconnect time, publish conflicts, lost comment anchors, and whether every replica reaches the same result. Launch single-user editing first, then online collaboration, offline work, and finally agents.

Why this mattersMetrics should cover user speed, system safety, and result quality. Rollout starts read-only and earns stronger automation with evidence.

Candidate · clear top-down answerOffline support makes the merge logic complex. If offline editing is not important, a simpler server-ordered design may be better. Never use the moving draft as a release input; always publish one fixed revision.

Why this mattersEvery design choice has a cost. Name the simpler alternative and explain which requirement makes the added complexity worth it.

Candidate · clear top-down answerIn short: drafts are fast, local, and mergeable; published versions are fixed and carefully checked. Stable block IDs preserve meaning, agents only suggest changes, and one strong publish step turns a changing draft into trusted input.

Why this mattersThe recap should repeat the user flow, the main trust rule, the hardest failure, and the most important trade-off—not every component.