System Design Interview
Google‑Docs–style collaborative editor with real‑time multi‑cursor editing, presence, rich content, offline support, and strong permissions.
Single service for documents, realtime, and history with one database.
What was missing: Edge protection, realtime isolation, caches, and async pipelines.
Why that's risky: SPOF; slow fanout under load.
What gets added: Nothing yet (MVP).
Trade-offs: Fast to ship; limited correctness and scale.
Add ingress protection and separate REST API from persistence.
What was missing: Ingress protection and clear separation of concerns.
Why that's risky: Origin overload and no quotas.
What gets added: Edge + rate limiting + API split.
Trade-offs: Quota config overhead.
Add websocket gateway and collaboration service with history and presence.
What was missing: Dedicated realtime path and history persistence.
Why that's risky: High p99; data loss on restarts.
What gets added: Realtime gateway, collaboration/presence services, history store.
Trade-offs: More services and state management.
Introduce async change pipeline for merge/index; keep user path lean.
What was missing: Async pipeline for costlier work and search.
Why that's risky: Blocking merges/indexing in user path raises p99.
What gets added: Change queue + merge worker + search index.
Trade-offs: Eventual index consistency and lag.
Add media handling, session-state caching, and read replicas while serving static content through a CDN.
What was missing: Media handling, low-latency session state, and read scaling for document fetches.
Why that's risky: Large blobs in DB, expensive room-state reads, and slower global document loads would hurt collaboration quality.
What gets added: Media service + blob store + CDN, a Redis-like session cache, and document read replicas.
Trade-offs: Replica lag, cache invalidation, and more coordination between ephemeral session state and durable document storage.
Harden security and operations with authZ, pub-sub fanout, notifications, DLQ handling, and observability.
What was missing: Dedicated authZ, external notifications, pub-sub fanout, durable audit, DLQ handling, and deep observability.
Why that's risky: Privilege bugs, weak operator visibility, and tightly coupled side effects would make failures harder to isolate and recover from.
What gets added: Permissions service, pub-sub bus, notification service, audit DB, DLQ, repair worker, and monitoring stack.
Trade-offs: More infrastructure, more eventual consistency between subsystems, and more operational coordination during incidents.
CRDTs guarantee convergence without a central server but are heavier; OT with a central transformer is simpler and efficient for text. Choose based on offline needs and operation semantics.
Buffer ops locally with session IDs and lamport/hybrid clocks; on reconnect, submit to a sync/repair pipeline that deduplicates, orders, and merges changes; surface conflicts in UI when needed.
All access decisions and mutations: who viewed/edited, share link grants, permission changes, doc ownership transfers, and administrative overrides; retain immutable logs with secure retention.
Create deterministic simulations of concurrent edits, fuzz op sequences, and validate snapshot equality across replicas; run load tests for fan‑in/out and operation latency distributions.
Use time‑bounded, scope‑limited tokens for share links; enforce authZ centrally via a permissions service; log all grants and revocations to an audit store.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
