Beginner
Open
Free
Turning a Vague Prompt into Requirements
The interviewer says: "Design a system like Google Docs." Nothing more.
- Write the 4–6 clarifying questions you would ask in the first five minutes, and for each say which design decision the answer changes.
- Propose a functional scope (in-scope and explicitly out-of-scope) for a 45-minute interview.
- State the non-functional requirements you would assume if the interviewer says "you decide", with a one-line justification each.
Solution
1. Clarifying questions and what they change
- Is real-time collaborative editing (multiple cursors, live merges) required, or is it "one editor at a time"? — Decides whether the core problem is conflict resolution (OT/CRDT) or a simple document store.
- How many concurrent editors per document, and how many documents / DAU? — Decides whether a single-server-per-document model works (typical: tens of editors per doc) and how many document servers.
- What is the acceptable latency for seeing another user's keystroke? — Sub-second means persistent connections (WebSockets) and in-memory document state; seconds allow polling.
- Do we need version history / undo across sessions? — Adds an append-only operation log and snapshotting.
- Offline editing and later sync? — Pushes strongly toward CRDTs and client-side state.
- Permissions and sharing? — Usually out of scope, but confirm.
2. Proposed scope
In scope: create/open a document; multiple users edit the same document concurrently and see each other's changes within ~1 s; changes are never lost; version history at coarse granularity.
Out of scope (say it, write it in the corner): rich media embedding, comments, permissions/ACLs beyond "shared with link", search, offline mode, export formats.
3. Assumed non-functional requirements
- Scale: 10 M DAU, ~1 M concurrently open documents, ≤ 20 concurrent editors per document — large but lets each document be owned by one server at a time.
- Latency: < 200 ms to propagate an edit to other editors in the same region — perceived as "live".
- Consistency: all editors converge to the same document (eventual convergence with causal ordering); strong consistency per document is acceptable because one server serialises each document's operations.
- Availability: 99.9% — an outage is annoying, not catastrophic; this avoids over-engineering multi-region active-active in 45 minutes.
- Durability: no accepted edit may be lost — replicate the operation log synchronously before acknowledging.
Stating these first makes every later choice justifiable with "because we agreed X".
Share this question