Design the backend for a real-time collaborative document editor (like Google Docs). Focus on conflict resolution and consistency.

system-design · Senior level · software-engineering

What the interviewer is really asking

Probes understanding of distributed state synchronization, operational transformation or CRDTs, and WebSocket-based real-time architecture.

What to say

• Use WebSockets for real-time bidirectional communication between client and server — HTTP polling is too slow.
• Conflict resolution: operational transformation (OT) or CRDTs (conflict-free replicated data types). OT: each operation is transformed against concurrent operations so all clients converge. CRDTs: data structures that merge automatically without conflicts. OT is complex to implement correctly; CRDTs are simpler but may use more memory.
• Architecture: a document session server (stateful, holds the document's current state and connected clients), a persistence layer (store document snapshots + operation log), and a presence layer (who's editing what, via ephemeral state — Redis pub/sub).

What to avoid

• Use last-write-wins without mentioning the data loss problem.
• Propose REST polling as the sync mechanism.
• Ignore the collaborative conflict case entirely.

Example answers

Strong: I'd use OT with a central server as the arbiter: clients send ops with a revision number. The server serializes ops, transforms any concurrent ones, and broadcasts the transformed op to all clients. This is how Google Docs works — the server is the source of truth for ordering.

Weak: Use a database lock — only one user can edit at a time.