Worked Scenario: Design a Real-Time Collaborative Editor's Frontend

A real-time collaborative editor is one of the hardest and most revealing frontend system design prompts, precisely because getting typing latency wrong is instantly, viscerally obvious, and getting conflict handling wrong silently loses someone's work. This scenario leans harder on the state management stage than the others, and is a good test of whether that material actually transferred.

Clarifying requirements

Assume: multiple users edit the same document simultaneously, seeing each other's changes live; the document is private, accessed only by collaborators with permission; typing must feel instant, with no perceptible lag between a keystroke and it appearing on screen; and momentary network issues shouldn't corrupt the document or silently drop someone's edits.

Rendering strategy: this is a CSR problem, and stating why matters

None of the reasons to prefer SSR, SSG or ISR apply here: this content isn't public, isn't meant to be indexed, and there's no anonymous first-time visitor whose fast first paint matters — every user is an authenticated collaborator loading into an ongoing, continuously-interactive session. The entire experience, from the moment the document loads, is driven by local interaction and live updates from other clients — the textbook CSR case, and naming why (rather than reflexively picking CSR because it's a text editor) is what demonstrates the reasoning transferred from the rendering stage rather than being pattern-matched.

The typing-latency problem: optimism, escalated

Every keystroke must update the local view immediately — this is the optimistic-update principle from the state management stage, applied at the highest possible stakes: any perceptible delay between a keystroke and its appearance on screen reads as broken, not just slow. Locally, this is "simple" optimism: apply the change to the local document model right away, independent of network round trips.

Where this scenario gets genuinely harder: concurrent edits

A single-user optimistic update (like a like button) only has to handle one kind of failure: the server rejects my change. A collaborative editor has a second, harder problem: two collaborators can make optimistic local edits to overlapping parts of the document at nearly the same moment, and naive "last network write wins" would silently discard one of them — an edit a real person made, disappearing without any indication it happened.

This is conceptually what CRDTs (conflict-free replicated data types) and operational transformation exist to solve: both are mechanisms for merging concurrent, conflicting edits such that every collaborator's client eventually converges on the same final document, incorporating both edits correctly rather than one overwriting the other. The frontend-relevant takeaway isn't implementing either algorithm from scratch in an interview — it's recognizing that this specific requirement (concurrent edits from multiple collaborators, none of which should be silently lost) is precisely the problem class those tools exist for, and naming that is stronger than either ignoring the problem or hand-waving "we'll just sync it."

1. Step 1

   Collaborator A types a character

   Applied to A's local document view immediately — no waiting for a network round trip.

2. Step 2

   Collaborator B types nearby, at nearly the same moment

   Applied to B's local view immediately too — both edits exist locally, independently, before either has reached the other.

3. Step 3

   Both edits propagate

   Via the underlying sync mechanism (a CRDT-based merge, or an OT transform against the other's edit).

4. Step 4

   Every client converges

   A's client, B's client, and any other collaborator's client all end up rendering the same final document, incorporating both edits — neither is silently lost.

What's explicitly out of scope

Implementing a CRDT or OT algorithm from first principles is a genuinely deep, specialized problem — reasonable to name as "I'd use an existing, well-tested library (like Yjs or Automerge) rather than hand-roll this," rather than attempting to design the merge algorithm itself live. Presence indicators (showing collaborators' live cursors) and offline editing with later sync are both real, related problems worth naming as deliberately out of scope for a focused answer, rather than silently ignored.

What to remember

• The editing surface of a private, collaborative, per-session tool is a clear CSR case — none of SSR/SSG/ISR's usual justifications (SEO, anonymous-visitor first paint) apply.
• Typing latency is an escalated, highest-stakes application of the optimistic-update principle: every keystroke applies locally and instantly, independent of network round trips.
• Concurrent edits from multiple collaborators are a genuinely harder problem than single-user optimism — "last write wins" silently loses work, which is exactly what CRDTs and operational transformation exist to prevent.
• Naming "I'd use an existing, proven library for the merge algorithm" is a stronger, more senior answer than attempting to design a CRDT from scratch under interview time pressure.