Q290: Realtime Collaboration System Design Conflicts and Presence

What Interviewers Want To Evaluate

Interviewers want to know whether you can design collaborative frontend systems beyond "use WebSockets."

They are checking presence, shared state, conflict resolution, optimistic updates, offline behavior, permissions, event ordering, snapshots, and recovery.

Short Interview Answer

Realtime collaboration design starts by deciding what state is shared, who can edit it, how updates are ordered, how conflicts are resolved, and how clients recover after reconnect. WebSockets or SSE are only transports. The system also needs snapshots, operation or event models, presence, permissions, optimistic UI, offline behavior, stale-state indicators, and observability. For rich text or shared documents, CRDTs or operational transforms may be appropriate; for simpler workflows, last-write or field-level conflict rules may be enough.

Detailed Interview Answer

Collaboration is state synchronization under uncertainty.

Users may:

edit at the same time
go offline
reconnect later
change permissions
open multiple tabs
receive events out of order
see stale presence
submit conflicting mutations

A strong design names these cases explicitly.

Shared State

First identify what is shared.

Examples:

document text
cursor position
selection
comments
task status
whiteboard objects
study plan
presence
typing indicators

Not all shared state deserves the same durability.

Presence can be ephemeral.

Document edits must be durable.

Transport

Transport options:

WebSocket
SSE
long polling
WebRTC for peer-heavy cases

WebSocket fits bidirectional collaboration.

SSE can fit server-to-client updates with normal HTTP mutations.

Transport is only one part of the design.

Snapshot and Events

Clients often need:

initial snapshot
stream of changes
last seen event ID
reconnect resume
full refresh fallback

Without snapshots, reconnect is fragile.

Without event IDs, missed updates are hard to detect.

Conflict Resolution

Conflict strategy depends on data type.

Options:

last write wins
field-level merge
server-side conflict rejection
manual conflict UI
operational transform
CRDT

Do not use CRDTs for every collaboration problem.

They are powerful but complex.

Use them when concurrent edits to the same structure must merge automatically.

Presence

Presence usually includes:

who is online
where they are
what they are editing
cursor or selection
last active time

Presence should expire.

Stale presence is worse than no presence.

Use heartbeat or server timeout.

Permissions

Collaboration permissions must be enforced server-side.

Check:

can user view?
can user edit?
can user comment?
can user invite?
can user see presence?
can user access history?

Permissions can change during a session.

The client must handle revocation.

Optimistic UI

Optimistic updates make collaboration feel responsive.

But the client must handle:

server rejection
conflict
operation reorder
duplicate event
rollback
confirmation

Show sync state clearly.

Users should know whether changes are saved, pending, offline, or failed.

Offline Behavior

Offline collaboration is hard.

Decide:

can users edit offline?
how are operations queued?
how are conflicts resolved?
what is stored locally?
how are permissions revalidated?
how is user warned?

If offline edit is not supported, say so clearly.

Interview Example

If asked, "Design collaborative notes for Learning Studio," answer:

"I would start with a document snapshot API, WebSocket channel for updates and presence, server-side permissions, operation IDs, reconnect resume from last event, pending/saved/offline UI states, and a conflict strategy. For rich text concurrent editing, I would consider CRDTs; for simple notes, field-level conflict or server rejection may be enough."

Common Mistakes

Common mistakes include:

saying only use WebSockets
no reconnect recovery
no conflict strategy
presence never expires
permissions checked only at connection
no stale-state UI
offline edits without merge plan
no event IDs

Senior-Level Framing

The senior framing:

"Realtime collaboration is shared state with unreliable networks and multiple writers. I design snapshots, events, permissions, conflict resolution, presence, optimistic UI, and recovery before choosing transport."

Practice Prompt

Design collaborative study notes with:

two editors
comments
presence
offline read
optional offline edit
permission changes
history

Define transport, state model, event shape, conflict strategy, and UI states.

Final Mental Model

Collaboration is not realtime transport.

It is agreement: who can change what, in what order, with which recovery path when the network disagrees.