How the interviewer opens it
“Design a database for flexible JSON-like documents with secondary indexes and document queries. It must support sharding and replication as collections grow.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Interview priorities
- Data and document semantics
- Traffic and latency
- Secondary indexes
- Query support and resource limits
- Consistency and query freshness
- Retries
- Replication and durability
- Collection growth
- Implementation boundary
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Create, read, replace, and delete flexible JSON documents
- Run indexed queries and create indexes during normal traffic
- Expand collections across shards without a full outage
- Replicate writes and preserve acknowledged results after one replica failure
Usually out of scope
- Transactions across documents
- Unique secondary indexes
- Joins, aggregates, text search, and array queries
- Cross-region replication
- A new storage engine
What interviewers ask about
- Document queries
- Flexible types complicate index order. Queries can reach every shard, and a small result can require substantial work.
- Writes during failures
- A document change also changes index entries. Failures must preserve acknowledged writes, fresh queries, and retained retry results.
- Collection growth
- Data moves while clients read and write it. A failed move must preserve ownership, deletes, query freshness, and retry history.
- New indexes
- A new index must cover old documents and concurrent changes. Its scan can exhaust disk space or delay normal writes.
Common mistakes
- Uses an existing document database as the entire answer.
- Allows stale index results because queries lack a common snapshot.
- Treats an idempotent write as sufficient to return the original retry result.
- Assumes every query can reach one shard because each document has an ID.
- Promises cheap queries because each page contains at most 100 documents.
- Copies data or creates indexes without concurrent changes and deletes.
The bar by level
- Senior (L5/E5)
- Completes the required query and write paths within the first 30 minutes. Explains fresh local read points, atomic index changes, quorum acknowledgement, sorted merge, and query limits. States a basic approach for retries, new indexes, and data moves. Explores one selected extension, including a failure and recovery path. The grader does not require detailed protocols for the other extensions.
- Staff (L6+/E6+)
- Uses the same required coverage and one-extension limit. Gives a clear safety argument for acknowledged writes and fresh query results. Quantifies shard fanout and identifies a capacity limit. For the selected extension, defines durable state, operation order, and recovery at each transition. Explains which guarantees require an availability error during failures. The grader does not require detailed protocols for the other extensions.