Imagine a campfire. One person starts a story — “Once upon a time, in a kingdom built on the back of a sleeping dragon…” — and then, instead of finishing it alone, they pass the story to the person next to them. That person adds a line. Then the next person adds a line. The story grows, twists, and surprises everyone, including the people who started it. Now imagine that campfire has ten thousand people sitting around it, all trying to add their line at the exact same second, from phones and laptops scattered across the planet, and the story still has to make sense, stay saved forever, and never lose a single word. That, in essence, is what a real-time collaborative story writing platform is: a system that lets many people write into the same living document at the same time, safely, quickly, and without chaos.

This idea did not start with technology — it started with games. Long before computers, people played “exquisite corpse,” a parlor game invented by surrealist writers in the 1920s, where each person wrote a line of a poem or story, folded the paper to hide it, and passed it on. The internet turned this analog game into something continuous and infinite. Early web forums in the 1990s hosted “round-robin” story threads, where users took turns posting chapters. Then came dedicated fan-fiction communities — Fanfiction.net (1998), and later Archive of Our Own, AO3 (2009) — which let fans of books, shows, and games write their own extended stories set in those universes, though mostly asynchronously (one author writes, others read and comment later, not truly at the same time).

The shift to genuinely real-time collaboration came from a different lineage: collaborative document editing. Google Docs, launched in 2006 (built on the acquired “Writely” and “Google Sheets” technology), proved that multiple people could type into the same document and see each other’s cursors and characters appear instantly. That same real-time engine — originally built for business memos and spreadsheets — is the direct technical ancestor of what we are designing here. Take Google Docs’ real-time sync engine, point it at creative fiction instead of business documents, add chapters, branching storylines, character sheets, comment threads, and a social layer for fandoms, and you get a collaborative storytelling platform: a blend of Google Docs, Wattpad, AO3, and Discord.

Before drawing a single box on an architecture diagram, we need to be precise about what problem we are solving and why it’s genuinely hard. Writing a story alone is a solved problem — that’s just a text editor. The difficulty appears the moment you allow more than one person to edit the same passage at the same time.

2.1 The core tension

Two writers, Aisha and Ben, are both looking at the sentence: “The dragon opened one eye.” Aisha starts typing at the end: “…and looked directly at the village.” At the very same moment, Ben places his cursor in the middle and types: “…slowly,” after “eye.” Both edits leave their machine within milliseconds of each other. If the server just applies them in the order they happen to arrive, one person’s intention can silently corrupt the other’s — inserting text at the wrong character position, splitting words, or losing content outright. Multiply this by hundreds of simultaneous editors across a large collaborative fan-fiction “war room,” and naive last-write-wins logic turns a shared story into garbled nonsense within seconds.

2.2 What makes this harder than a typical CRUD app

2.3 Goals

• Functional: multiple users edit the same story/chapter concurrently with live cursors and presence; changes converge to an identical final document for everyone; version history and rollback; branching for “alternate timelines”; comments, reactions, and chapter-level publishing; rich text and inline media (images, character cards).
• Non-functional: sub-100ms edit propagation within a region; eventual, guaranteed convergence across all replicas (no diverging copies of the story); horizontal scalability to millions of concurrent editing sessions; 99.95%+ availability; durability — a submitted keystroke must never be silently lost; strong abuse/spam resistance given open, public collaboration.

3.1 Operational Transformation (OT)

What: OT is an algorithm that takes two edits made concurrently (before either has seen the other) and mathematically “transforms” one against the other so both end up producing the same final text, no matter what order they’re applied in.

Where used: Google Docs, Etherpad, early collaborative editors. Requires a central server to serialize the order of operations, which makes it simpler to reason about but harder to make peer-to-peer or fully offline-tolerant.

3.2 Conflict-Free Replicated Data Types (CRDTs)

What: A CRDT is a data structure specially designed so that if two or more copies of it are modified independently (even offline, even in different order) and then merged, they mathematically always converge to the same final state — with no central coordinator required, and no possibility of conflict.

Where used: Figma, Notion (partially), Automerge, Yjs — most modern collaborative editors have shifted toward CRDTs because they tolerate offline editing and peer-to-peer sync far better than OT.

3.3 Why this system leans CRDT over OT

Fan-fiction and story writing has two properties that favor CRDTs specifically: writers frequently go offline (drafting on a plane, a subway, a phone with spotty signal) and then reconnect with a burst of local edits to merge; and the product wants branching (alternate story timelines), which is naturally modeled as forking and later merging replicas of a CRDT document — very similar to how Git forks and merges branches of code.

3.4 Presence & Awareness

What: Beyond the text itself, users need to see where other people are — colored cursors, selection highlights, “Ben is typing…” indicators, and avatars in the margin. This is called “awareness” state, and it is deliberately treated as ephemeral (not persisted to the database, not part of the CRDT), because losing a cursor position on reconnect is harmless, unlike losing actual story text.

3.5 CAP Theorem in this context

The CAP theorem says a distributed system can only fully guarantee two of Consistency, Availability, and Partition tolerance at once. For collaborative editing, we deliberately choose AP (Availability + Partition tolerance) with eventual consistency: every writer should always be able to keep typing, even during a network partition, and all replicas will converge once the partition heals. We never want a writer’s keystrokes to be rejected because “the system can’t guarantee strict consistency right now” — that would destroy the writing experience. CRDTs are, in fact, a purpose-built tool for building AP systems with mathematically guaranteed eventual convergence.

3.6 Choosing the transport protocol: WebSocket vs. SSE vs. long polling

Real-time systems have three common transport choices, and interviewers often want to hear you reason through all three rather than jumping straight to “WebSocket” by memory.

We settle on WebSocket for the live-editing channel specifically because it is bidirectional and low-overhead per message once established, which matters enormously when a single active writer might generate dozens of tiny operations per second. SSE remains useful as a secondary, simpler channel for one-way notifications (e.g., “a comment was posted”) where a full duplex socket would be overkill.

3.7 Data structure choice for the text itself: array, rope, or tree?

Beneath the CRDT layer sits a more basic question: what in-memory data structure actually stores the characters of a chapter that might grow to 50,000+ words? A naive contiguous character array makes insertion in the middle an $O(n)$ operation — copying every character after the insertion point — which becomes painfully slow for a long chapter edited thousands of times. Three realistic choices:

In production, the RGA linked structure is paired with an auxiliary balanced-tree index (mapping visible character offsets to node references), so that “insert at cursor position 4,532” doesn’t require walking 4,532 linked-list nodes one at a time — it resolves in logarithmic time, keeping typing responsive even in very long chapters.

3.8 Consensus & leader election for sharded actors

Although CRDT merge itself needs no consensus (that’s the whole point), the infrastructure around it still needs a way to agree on which node currently owns which story’s actor, so that two nodes don’t both believe they’re authoritative for the same shard during a rebalance or failover. We use a lightweight consensus layer (e.g., etcd or ZooKeeper, built on the Raft consensus algorithm) purely for this ownership/leader-election bookkeeping — a small, well-understood problem — while keeping the actual document merge logic consensus-free and highly available. This separation is deliberate: we don’t want the availability of the whole writing experience to depend on a consensus quorum being reachable; we only want shard ownership decisions to go through consensus, and even a brief unavailability there just delays a rebalance, it doesn’t block anyone from typing.

Below is the high-level architecture. Every box represents a distinct, independently scalable component. Notice the split between the synchronous request path (REST calls through the API Gateway for things like login, browsing stories, publishing chapters) and the real-time path (persistent WebSocket connections through a dedicated Realtime Gateway for live character-by-character editing).

4.1 Component-by-component breakdown

This is usually the section that separates a strong system design answer from a great one. Let’s walk through exactly how a keystroke travels from Aisha’s keyboard to Ben’s screen and back, and why the merged result is guaranteed to be identical for everyone.

5.1 The RGA (Replicated Growable Array) approach

A popular, interview-friendly CRDT structure for text is the Replicated Growable Array (RGA). Instead of storing text as “characters at positions” (position 0, 1, 2…), each character is given a permanent, globally unique ID made of (user_id, logical_clock), and a pointer to the ID of the character it was inserted after. This turns the document into a linked list of immutable, uniquely-identified nodes rather than a mutable array — insertion never has to “renumber” anything, which is exactly what makes concurrent inserts conflict-free.

5.2 Step-by-step: two concurrent inserts

1. Aisha’s client has local text “…eye.” and types “d” — creating a new node {id:(aisha,102), after:(dot_char_id), value:'d'}, applies it optimistically to her own local view instantly (this is what makes typing feel instant), and sends it to the Collaboration Engine over the WebSocket.
2. Ben’s client, unaware of Aisha’s edit, types “ slowly” after “eye” at nearly the same moment — creating its own chain of nodes anchored to the same “eye” node.
3. Both operations arrive at the Collaboration Engine’s document actor (possibly out of order, since network latency varies). The actor applies each operation to its authoritative CRDT state using the RGA insertion rule: “insert this node immediately after the node with this ID; if another node is already there, use the tie-break rule (compare origin user IDs) to decide left/right ordering.”
4. Because the merge rule is commutative and deterministic — the same final order results no matter which operation is applied first — the actor’s resulting state is well-defined and identical regardless of arrival order.
5. The actor broadcasts both operations (not the full document — just the deltas) to every other connected client via the Pub/Sub layer, including back to Aisha and Ben themselves for acknowledgment.
6. Every client applies the same two operations using the same deterministic merge rule, so all replicas — server and every browser tab — converge to the exact same final text, even though Aisha and Ben never saw each other’s edit before typing.

public class CollaborationEngine {

    // Each node: unique id, the id it was inserted after, its character, and a tombstone flag for deletes
    private final Map<OpId, RgaNode> nodes = new ConcurrentHashMap<>();
    private final OpId HEAD = OpId.sentinel();

    // Applies an insert operation; safe to call in any arrival order
    public synchronized void applyInsert(InsertOp op) {
        RgaNode newNode = new RgaNode(op.id(), op.afterId(), op.value());
        RgaNode anchor = nodes.getOrDefault(op.afterId(), RgaNode.head(HEAD));

        // Tie-break concurrent inserts at the same anchor by comparing (timestamp, userId)
        RgaNode sibling = anchor.firstChild();
        while (sibling != null && sibling.id().compareTo(op.id()) > 0) {
            anchor = sibling;
            sibling = sibling.nextSibling();
        }
        anchor.insertChildAfter(newNode);
        nodes.put(op.id(), newNode);
    }

    // Deletes are tombstones, never physical removals - required for correct concurrent merge
    public synchronized void applyDelete(DeleteOp op) {
        RgaNode target = nodes.get(op.targetId());
        if (target != null) target.markTombstoned();
    }

    // Renders the current visible text by walking the linked structure, skipping tombstones
    public String renderText() {
        StringBuilder sb = new StringBuilder();
        for (RgaNode n : traverseInOrder(HEAD)) {
            if (!n.isTombstoned()) sb.append(n.value());
        }
        return sb.toString();
    }
}

5.3 Deletes: tombstones, not removals

A critical, often-missed detail: when text is deleted, the CRDT does not physically remove the node. It marks it as a tombstone (invisible, but still present in the structure). This matters because another client, offline at the time of the delete, might still send an operation anchored to that “deleted” character’s ID — if the node were truly gone, that anchor reference would be broken. Tombstones are periodically garbage-collected only once we’re certain no offline client can still reference them (typically after a safe retention window, e.g. 30 days).

5.3.1 Why this level of detail matters

It’s tempting to treat “we use a CRDT” as a sufficient answer and move on, but the specific mechanics — unique per-character identity, anchor-based insertion, tombstoned deletes, deterministic tie-breaking — are exactly what an interviewer is probing for when they ask a follow-up like “walk me through what actually happens when two people type at the same position.” Being able to describe the RGA structure concretely, rather than gesturing vaguely at “some conflict-free algorithm,” is usually the difference between a design that sounds correct and one that’s been genuinely reasoned through.

5.4 Snapshotting & the operation log

Replaying every single character-insert operation from the beginning of a long-running story would be slow. So the Collaboration Engine periodically (e.g., every 200 operations or 60 seconds) writes a compacted binary snapshot of the current CRDT state to the Document Store, alongside a trimmed operation log of only the ops since that snapshot. Reconnecting clients (or a freshly-spun-up actor after a crash) load the latest snapshot plus replay the small remaining log — turning an $O(text{all history})$ load into an $O(text{recent ops})$ load.

5.5 Concurrency & thread safety within a single actor

Even though CRDT merges are conflict-free at the data-structure level, the Collaboration Engine process itself still needs to handle many simultaneous incoming operations for the same story without corrupting its in-memory structures — a classic concurrent-programming problem, separate from the distributed-merge problem. Two practical approaches: (1) the actor-per-document model, where each document’s operations are processed strictly sequentially by a single dedicated worker thread or event loop (via an internal queue), sidestepping the need for fine-grained locking entirely — simpler to reason about, at the cost of pinning one document’s throughput to a single thread’s speed; or (2) fine-grained locking/synchronization (as shown in the earlier Java example’s synchronized methods) allowing multiple threads to process different documents’ operations in parallel within one process, while still serializing access to any single document’s shared state. In production, most systems favor the actor-per-document model for its simplicity and predictability, reserving thread-pool parallelism for spreading many different documents’ single-threaded actors across available cores, rather than trying to parallelize a single document’s operation stream.

This matters for an interview answer because it shows you understand that “conflict-free” at the CRDT-algorithm level does not automatically mean “thread-safe” at the implementation level — those are two different concurrency problems solved by two different techniques, and conflating them is a common gap in weaker answers.

Let’s trace a chapter from “blank page” to “published, searchable story” end to end.

6.1 Branching and version control, in more depth

Branching deserves special attention because it’s the feature that most distinguishes this system from a plain collaborative editor like Google Docs. When a writer forks a chapter into an alternate timeline, the platform doesn’t copy the rendered text as a dumb string snapshot — it clones the underlying CRDT structure itself, including every character’s unique identity and causal history up to the fork point. This has a genuinely useful consequence: because both the original and the forked branch share the same character-identity scheme up to the divergence point, it’s technically possible (and a compelling advanced feature) to later compute a structural diff between two branches, or even offer a “cherry-pick this paragraph from the alternate branch back into canon” merge operation, using much of the same conflict-free merge machinery that powers everyday concurrent editing. This is analogous to how Git branches share commit history up to a fork point, enabling diffing and selective merging long after the branches have diverged.

Version history more broadly is simply a query over the same durable, ordered operation log used for crash recovery — “what did this chapter look like at 3:00pm yesterday” is answered by replaying the nearest snapshot before that timestamp plus the subsequent operations up to it. Because this reuses infrastructure we already need for reliability (Section 9) and internal recovery (Section 5.4), version history is close to “free” from an infrastructure standpoint once the event-sourced foundation is in place — a good example of how a sound core architectural decision pays for a valuable product feature almost incidentally.

7.1 Key trade-off table

None of these trade-offs are free wins — each column in the table above represents a real cost accepted in exchange for a real benefit, and a mature design discussion should acknowledge both sides rather than presenting the chosen option as strictly superior in every dimension. The common thread across all five decisions is a consistent bias toward availability and collaborative continuity over strict correctness guarantees or storage efficiency — a bias that is the right one for a creative, social writing product, but would be the wrong one for, say, a financial ledger system where strict consistency is non-negotiable. Good system design is rarely about finding a universally “correct” answer; it’s about picking the trade-offs that best fit the specific product’s priorities, and being able to articulate why.

8.1 Sharding the Collaboration Engine

We shard document actors by story_id (or chapter_id for very large multi-author stories) using consistent hashing across a fleet of Collaboration Engine nodes. This means: a wildly popular collaborative story with thousands of simultaneous editors gets its actor(s) pinned to well-provisioned nodes, while millions of quiet, single-author stories share nodes cheaply — true multi-tenant efficiency.

8.2 Scaling WebSocket connections

A single well-tuned gateway node can typically hold 50,000-100,000 concurrent idle-ish WebSocket connections (bounded mostly by memory per connection and file descriptor limits, tuned via OS-level settings). We scale this fleet horizontally behind the load balancer, and because gateway nodes are stateless routers (state lives in the Collaboration Engine / Pub-Sub layer), we can autoscale on connection-count metrics without any handoff complexity.

8.3 Why “sticky sessions” are avoided

A naive design sticks a WebSocket client to one gateway node and requires that same node to hold document state — this creates hot-node problems (a viral story’s editors all pin to one node) and painful failover (losing that node loses live document state). Instead, gateway nodes are dumb routers; actual document state lives in the Collaboration Engine, addressed by story_id via consistent hashing, and reachable from any gateway node through the Pub/Sub layer. This decouples “which gateway a client is connected to” from “which node owns the document,” so both scale independently.

8.4 Batching & back-pressure

To avoid flooding the network with one message per keystroke, clients debounce/batch tiny operations (e.g., 20-50ms windows) before sending, and the Collaboration Engine applies back-pressure (bounded queues with drop-oldest-presence-update policies, never drop-oldest-edit) if a downstream consumer falls behind.

8.5 Back-of-the-envelope capacity estimation

A thorough interview answer usually includes rough numbers, even approximate ones, to show the design was sized rather than guessed. Let’s estimate for a platform with 20 million monthly active writers.

These numbers exist to sanity-check design decisions, not to be memorized precisely: they confirm, for example, that bandwidth is comfortably within reach of standard networking (hundreds of Mbps, not many Gbps), that WebSocket connection count — not raw CPU — is the more binding constraint on gateway sizing, and that the Collaboration Engine’s real scaling driver is operations-per-second-per-shard rather than a simple connection count, which is exactly why we shard and autoscale on that custom metric rather than on generic CPU utilization.

8.6 Storage growth estimation

If the average published story reaches 20,000 words (~120,000 characters) and each character’s CRDT metadata adds roughly 24 bytes of overhead (unique ID, origin pointer, tombstone flag) on top of the 1-byte character itself, a single story’s raw CRDT representation could reach roughly 3 MB before compaction. With snapshotting and tombstone garbage collection, steady-state storage per completed story typically compresses down to a few hundred KB — still meaningfully larger than plain text, which is the direct, expected cost of CRDT metadata discussed in the trade-offs section, and a key reason snapshot compaction isn’t optional at scale.

9.1 No single point of failure

Every stateless tier (API Gateway, WebSocket Gateway, Story Service, Moderation, Notification, Search) runs as a multi-node, auto-healing fleet behind the load balancer. The Collaboration Engine, while “stateful” per document, replicates each active document actor’s in-memory state to at least one hot standby via the durable operation log, so a node failure triggers fast failover (replay the last snapshot + recent ops on a new node) rather than data loss.

9.2 Multi-region & disaster recovery

The system runs active-active across multiple regions for the stateless tiers, with GeoDNS routing writers to their nearest region for latency. The Document Store and Kafka use cross-region replication (async, eventually consistent) so a full regional outage can be failed over to a secondary region with a bounded (typically single-digit-second) recovery point objective. Because CRDTs merge cleanly even across a region failover’s small window of divergence, this is one of the rare architectures where cross-region active-active writing is genuinely tractable.

9.3 Graceful degradation

• If the Moderation Service is degraded, allow publishing to proceed with async, delayed moderation rather than blocking all writers.
• If Search is down, story browsing falls back to cached “popular/recent” lists instead of failing entirely.
• If the Pub/Sub layer has a brief hiccup, clients buffer local operations and replay them once reconnected — nothing is lost because of client-side optimistic application plus durable server-side logging.

9.4 Backups

Document snapshots and operation logs are backed up to Object Storage on a rolling schedule, with point-in-time recovery supported by replaying the operation log up to any target timestamp — which doubles conveniently as the “story version history / time travel” product feature.

9.5 Chaos engineering

Given how much this system’s reliability story depends on graceful recovery rather than avoiding failure entirely, regular chaos experiments are essential rather than optional polish. Representative experiments: randomly killing Collaboration Engine nodes mid-session to verify actor failover and snapshot recovery actually work under real load (not just in unit tests); injecting artificial network partition between regions to confirm CRDT convergence behaves correctly once the partition heals; and throttling the Pub/Sub layer to verify client-side buffering and reconnect logic degrade gracefully rather than dropping edits. Running these experiments regularly in a controlled way, rather than discovering the failure mode for the first time during a real incident, is what actually earns the 99.95% availability target rather than just aspiring to it on paper.

9.6 Disaster recovery runbook (summary)

1. Detect: automated alerting fires on regional health-check failures or a sustained spike in client reconnect/error rates.
2. Contain: GeoDNS and load balancer health checks automatically stop routing new connections to the impaired region within seconds.
3. Fail over: traffic for affected users is redirected to the nearest healthy region; Collaboration Engine actors for affected shards are recreated there from the latest replicated snapshot plus the replicated operation log tail.
4. Reconcile: once the impaired region recovers, any operations that occurred only in the failover region during the outage window are merged back via the same CRDT convergence guarantees used for everyday concurrent editing — disaster recovery reconciliation is, elegantly, just another instance of the same merge algorithm the system already relies on daily.
5. Review: a blameless post-incident review captures root cause and follow-up action items, feeding back into chaos engineering scenarios to catch the same class of failure earlier next time.

10.1 Authentication & authorization

OAuth2/OIDC for login (supporting social logins, common for fan-fiction communities), short-lived JWT access tokens plus refresh tokens, validated at the API Gateway and again at WebSocket handshake time. Per-story permissions (owner, co-author, editor, viewer) are enforced both at the REST layer and inside the Collaboration Engine — a viewer’s client should never even receive write-capable operation channels.

10.2 Content-layer risks specific to this system

What ties these four risks together is that they’re all consequences of the same product decision — opening up real-time, low-friction, mass collaborative writing to the public — that makes this system valuable in the first place. A design that eliminated all of these risks by, say, requiring heavy manual review before any text became visible to co-authors would also eliminate the real-time collaborative experience that is the entire point of the product. The security posture here is therefore necessarily about layered, mostly-automated mitigation with fast human escalation paths, not prevention that would compromise the core product.

10.3 Rate limiting algorithm choice

Not all rate limiters behave the same under bursty typing patterns, which matters here more than in a typical API. A fixed-window counter (e.g., “100 ops per user per 10-second window”) is simple but allows a burst of 200 ops right at a window boundary (100 at the end of one window, 100 at the start of the next). A sliding-window log or token-bucket algorithm is preferable: a token bucket refills at a steady rate (matching natural typing cadence) but allows short legitimate bursts (pasting a paragraph) up to the bucket’s capacity, then throttles sustained abuse smoothly rather than with hard cliffs. We apply token-bucket limiting per WebSocket connection for operation volume, and a separate, coarser fixed-window limiter at the API Gateway for REST calls like publishing or comment posting.

10.4 Data privacy & regulatory considerations

Because stories and their full edit history are retained (for version control and abuse-reversion purposes), the system must support privacy regulations like GDPR’s “right to erasure.” This is handled by separating authorship identity from content: when a user requests account deletion, their personal identity data (email, real name, login credentials) is purged from PostgreSQL, while their historical CRDT operations are retained but re-associated with an anonymized author token — preserving story integrity and other co-authors’ work without retaining the deleted user’s personal data. This distinction (delete identity, anonymize authorship, preserve content integrity) is a common and defensible pattern for collaborative platforms with legal retention tensions.

10.5 Transport & infrastructure security

• TLS everywhere, including for WebSocket connections (WSS), terminated at the load balancer with modern cipher suites.
• Rate limiting at the API Gateway (per-IP and per-user) and a separate, tighter rate limit on write-operation volume per WebSocket connection to blunt automated abuse or bugs causing operation storms.
• Secrets (DB credentials, signing keys) managed via a secrets manager (e.g., Vault/KMS), never hardcoded or logged.
• Principle of least privilege for service-to-service auth (mTLS or signed service tokens between internal microservices).

11.1 What to measure

11.2 Alerting philosophy

Alert on symptoms users would notice (rising P99 edit latency, WebSocket reconnect storms, snapshot failures) rather than only on low-level resource metrics — a CPU spike that doesn’t affect latency shouldn’t page anyone at 3am, but a latency regression should.

11.3 Distributed tracing example

Every operation carries a trace ID generated client-side, propagated through the WebSocket Gateway, Collaboration Engine, Pub/Sub, and back down to every recipient client. This lets engineers answer “why did this specific keystroke take 400ms to appear for Ben?” by inspecting a single trace spanning every hop, rather than correlating disjoint logs across five services by hand.

11.4 SLOs and error budgets

Rather than chasing “zero errors,” the team defines explicit Service Level Objectives with an accompanying error budget — for example, “99.9% of edit operations propagate to co-editors within 200ms, measured over a rolling 30-day window.” As long as the system is within its error budget, feature teams can ship changes at normal velocity; once the budget is nearly exhausted (too many slow-propagation events in the window), the team shifts focus to reliability work before shipping new features. This turns “how reliable should we be” from an argument into a measurable, pre-agreed policy, and is the same discipline widely used at large-scale consumer platforms to balance shipping speed against user-facing reliability.

12.1 Containerized, orchestrated microservices

All stateless services run as containers on Kubernetes, with Horizontal Pod Autoscalers tuned to each service’s real bottleneck resource — CPU for API Gateway, connection-count/memory for the WebSocket Gateway, and a custom metric (assigned-shards-per-node) for the Collaboration Engine.

12.2 Infrastructure as Code

Terraform (or equivalent) defines all cloud resources — VPCs, managed Kafka clusters, managed MongoDB/PostgreSQL, load balancers — version-controlled and peer-reviewed like application code, enabling reproducible environments and safe disaster recovery rebuilds.

12.3 Deployment strategy

Stateless services use rolling or canary deployments (small percentage of traffic shifted to the new version, monitored, then ramped). The Collaboration Engine, being stateful per-shard, uses a careful drain-and-migrate strategy: new code is deployed to fresh nodes, existing document actors are gracefully migrated (snapshot + handoff) rather than killed outright, minimizing mid-session disruption for active writers.

12.4 Multi-region topology

12.5 CI/CD pipeline

Every merge to the main branch triggers an automated pipeline: unit tests, integration tests (including CRDT convergence property tests — randomized concurrent operation sequences checked for deterministic final-state equality), a staging deployment, automated smoke tests against staging, and finally a canary rollout to a small percentage of production traffic with automatic rollback if error rates or latency regress beyond defined thresholds. The CRDT convergence tests deserve special emphasis: because correctness here means “any interleaving of concurrent operations produces the same final state,” we use property-based/randomized testing (generating thousands of random concurrent operation orderings per test run) rather than relying solely on hand-written example-based tests, since subtle merge bugs often only appear under orderings a human wouldn’t think to write by hand.

12.6 Cost optimization

The two largest cost drivers in a system like this are typically WebSocket Gateway connection capacity (paying for idle-but-open connections) and the Document Store’s storage/IO for CRDT metadata overhead. Practical levers include: right-sizing gateway instances around connections-per-core rather than defaulting to generic compute-optimized instance types; using spot/preemptible instances for stateless, easily-restartable tiers (API Gateway, Search indexing workers) while keeping the stateful Collaboration Engine on stable, reserved capacity; aggressive tombstone garbage collection and snapshot compaction to control storage growth; and tiered storage — moving long-inactive stories’ full operation history to cheaper cold object storage while keeping only the latest snapshot readily queryable.

13.1 Polyglot persistence rationale

13.2 Sharding strategy for the Document Store

Shard key: story_id (hashed). This keeps every operation for a given story co-located on the same shard (avoiding cross-shard transactions for the common case), while spreading unrelated stories’ load evenly. A secondary index on author_id supports “my stories” queries via the Story Service’s PostgreSQL layer instead, avoiding expensive cross-shard scatter-gather queries against MongoDB.

13.3 Caching strategy

• Cache-aside for hot documents: the Collaboration Engine keeps actively-edited CRDT state in memory (itself acting as the “cache”), backed by Redis as a secondary warm cache for recently-active-but-idle documents, before falling back to MongoDB for cold documents.
• Write-through for session/auth data: Redis is updated synchronously alongside PostgreSQL writes for permission changes, since stale permission caches are a real security risk.
• CDN edge caching for published (immutable-until-republished) chapters and static assets, with cache invalidation triggered on the “chapter.published” Kafka event.

13.3.1 Handling embedded media and structured character data

Beyond plain prose, collaborative fiction platforms typically also support embedded images (cover art, character portraits, scene illustrations) and structured “character sheets” (name, description, relationships, stats for role-playing-style collaborative fiction). These are handled deliberately outside the CRDT text stream: an inline image is represented in the text CRDT only as a lightweight reference node (an ID pointing to an Object Storage asset), while the actual binary image data is uploaded separately via a conventional pre-signed-URL upload flow to S3, keeping the latency-critical text-editing path free of large binary payloads. Structured character-sheet data, meanwhile, is modeled as its own smaller CRDT-backed document (following the same merge principles as chapter text, since two co-authors might simultaneously edit a shared character’s backstory), but stored and cached separately from chapter prose since it has different access patterns — read far more often relative to how often it’s edited, and typically edited by a small, stable set of co-authors rather than large open crowds.

13.4 Load balancing details

Layer 7 load balancing with least-outstanding-requests for the API Gateway fleet (better than round-robin when request costs vary). For the WebSocket Gateway, connection-count-aware balancing distributes new connections to the least-loaded node, since each connection carries ongoing memory/CPU cost for the node’s lifetime, unlike a quick REST request.

14.1 REST API surface (via API Gateway)

POST   /v1/auth/login
POST   /v1/stories                       // create a new story
GET    /v1/stories/{storyId}/chapters
POST   /v1/stories/{storyId}/chapters    // create a chapter (draft)
POST   /v1/chapters/{chapterId}/publish
POST   /v1/chapters/{chapterId}/branch   // fork into alt-timeline
GET    /v1/chapters/{chapterId}/history  // version timeline
POST   /v1/chapters/{chapterId}/comments
GET    /v1/search?q=&tags=
WS     /v1/realtime/chapters/{chapterId} // WebSocket upgrade for live editing

14.2 WebSocket protocol (simplified message shape)

public record RealtimeMessage(
    String type,        // "op" | "presence" | "ack" | "resync"
    String chapterId,
    String traceId,
    Object payload      // InsertOp / DeleteOp / CursorUpdate / SnapshotRef
) {}

public class RealtimeHandler {
    public void onMessage(Session session, RealtimeMessage msg) {
        switch (msg.type()) {
            case "op"       -> collabEngine.applyAndBroadcast(msg);
            case "presence" -> presenceService.update(msg);
            case "resync"   -> session.send(collabEngine.snapshotFor(msg.chapterId()));
            default         -> logger.warn("Unknown message type: {}", msg.type());
        }
    }
}

14.3 Why microservices, and how they’re split

Services are split along independent scaling and failure boundaries, not just “one microservice per noun.” The Collaboration Engine (stateful, latency-critical) is deliberately separated from the Story Service (stateless CRUD) even though both touch “story” data, because they have wildly different scaling profiles — one scales on active-editor count, the other on request rate. Similarly, Moderation and Notification are decoupled via the message broker so a slow moderation model never adds latency to the live editing path.

14.4 Service-to-service communication

Synchronous gRPC for low-latency, request/response internal calls (e.g., Story Service checking a user’s permission with Auth Service); asynchronous Kafka events for anything that can tolerate eventual delivery and benefits from decoupling (moderation, notifications, search indexing). This split avoids the classic mistake of chaining synchronous calls across many services, which would multiply tail latency and create cascading failure risk.

14.5 API versioning & backward compatibility

The WebSocket protocol is the riskiest surface to version, since millions of already-connected clients can’t simply “refresh” mid-session without disrupting active writers. We version the protocol explicitly in the connection handshake (a client declares its supported protocol version) and require the Realtime Gateway and Collaboration Engine to support at least the current and previous protocol versions simultaneously during any rollout, giving already-connected older clients a grace window to naturally reconnect on their own schedule (e.g., on their next page load) rather than forcing an immediate, disruptive mass-disconnect. REST endpoints follow more conventional URL-path versioning (/v1/, /v2/) with deprecation windows communicated well in advance.

Naming the right design patterns by their established terminology signals to an interviewer that your design choices are grounded in well-understood industry practice rather than improvised on the spot. Each pattern below maps directly to a specific decision made earlier in this document, and it’s worth being able to explain not just what the pattern is, but which concrete problem in this system it was chosen to solve.

15.1 Patterns worth naming in an interview

15.2 Anti-patterns to avoid

Each of these anti-patterns tends to look reasonable in isolation — often even appearing in an early prototype that “seems to work” in casual testing with two people in the same room — and only reveals its true cost once real, geographically distributed, flaky-network users start hammering the system concurrently at scale. Recognizing them early, before they’re load-bearing in production, is far cheaper than migrating away from them later.

16.1 Best practices

• Apply edits optimistically on the client before server acknowledgment. Perceived responsiveness is the entire product experience here — a writer who feels even a hundred milliseconds of lag on their own typing will notice it far more than any latency in seeing someone else’s edits, so the client must render its own keystrokes instantly and reconcile with the server’s authoritative merge only in the background.
• Keep the WebSocket protocol operation-based, never full-document-based. Sending the entire chapter on every keystroke doesn’t just waste bandwidth — it makes offline replay and conflict merging impossible to reason about correctly, since you lose the fine-grained intent of what actually changed.
• Treat presence/awareness data as strictly ephemeral. Cursor positions and typing indicators should never sit on the same durable, latency-sensitive write path as actual story content; mixing the two risks slowing down or complicating the one path (content durability) that genuinely cannot afford to fail.
• Snapshot regularly to bound both crash-recovery time and per-session load time as stories grow into the hundreds of thousands of words across a long-running fandom epic. Without this, a popular, years-old collaborative story could eventually take unacceptably long to load for a new reader or reconnecting writer.
• Design the operation log to double as version history from day one. Retrofitting proper version control onto a system that wasn’t built event-sourced from the start is a substantially harder migration than building it in up front, since it usually requires backfilling history that was never actually captured.
• Validate every incoming operation server-side; never trust client-computed positions, IDs, or permissions blindly. A compromised or buggy client is a realistic threat model for any system this open, and the Collaboration Engine is the last line of defense against structurally invalid operations reaching the shared document.
• Separate the “draft” (live, evolving) and “published” (immutable snapshot) states explicitly at the data model level, not just in the UI — this single modeling decision prevents an entire category of “readers saw content silently change underneath them” bugs.

16.2 Testing strategy for a collaborative system

Testing this kind of system requires going beyond typical unit and integration tests. Three additional layers matter specifically here: property-based convergence testing, where thousands of randomly generated concurrent operation sequences are applied in every possible interleaving and checked for identical final results, catching the subtle merge-order bugs that hand-written example tests would likely miss; chaos/fault-injection testing (Section 9.5), which validates that failover and reconnection logic behave correctly under real, simulated failures rather than only in the happy path; and load testing with realistic typing patterns — synthetic clients that mimic actual human typing cadence, pauses, and burst-paste behavior, rather than a flat, unrealistic constant request rate, since real bottlenecks (like snapshot compaction timing or presence-update flooding) often only appear under realistic, bursty usage patterns rather than smooth synthetic load.

16.3 Common mistakes

• Confusing “eventual consistency” with “no consistency guarantees at all” — CRDTs must still mathematically guarantee convergence, not just “usually work.”
• Forgetting tombstone garbage collection until memory usage on long-running popular stories becomes a production incident.
• Coupling WebSocket Gateway scaling to Collaboration Engine scaling as if they were the same tier — they have different bottlenecks and should scale independently.
• Under-provisioning for the “viral story” hot-spot case, since traffic in social creative platforms is famously long-tail with sudden spikes.
• Skipping abuse/rate-limiting until after a public launch, when open collaborative writing is an obvious spam/vandalism magnet from day one.

Studying these systems side by side reveals a recurring pattern worth internalizing for any collaborative-systems interview: the products that succeeded at scale (Google Docs, Figma) all made a deliberate, early, foundational choice about their conflict-resolution algorithm and never treated it as an implementation detail to bolt on later. Collaboration correctness is a load-bearing architectural decision, not a feature — it shapes what the data model can support (offline editing, branching, block-level structure), how the system scales, and how bugs manifest years later as the platform grows. Teams that under-invest in this decision early tend to pay for it later in the form of painful, user-visible data-corruption incidents that are difficult to retrofit away from.

“The best collaborative systems don’t just merge text correctly — they make everyone forget that merging is even happening.”A useful mental model borrowed from the Figma and Google Docs engineering teams’ public writing on real-time collaboration.

17.1 Lessons transferred into this design

Designing a real-time collaborative story writing platform is, at its core, an exercise in taking a genuinely hard distributed-systems problem — many people editing the same fine-grained content simultaneously, sometimes offline, sometimes across continents — and solving it in a way that stays invisible to the end user. Every architectural decision in this document traces back to that single goal: a writer should be able to type freely, at any time, from anywhere, and trust that their words and everyone else’s will always come together correctly. The technology (CRDTs, sharded actors, event sourcing, polyglot persistence) exists entirely in service of that simple, human promise.

If asked to defend one decision above all others in an interview setting, defend the conflict-resolution strategy. Everything downstream — the shape of the WebSocket protocol, the sharding strategy, the multi-region deployment model, even the version-history and branching product features — flows naturally once CRDTs are chosen as the foundation, and would need to be substantially rethought under a different foundational choice. Strong system design answers are rarely about listing every possible technology; they’re about correctly identifying the one or two decisions the rest of the system genuinely depends on, and reasoning about those with real depth.