How the interviewer opens it
“Design persistent network-attached block volumes for virtual machines. The service must provide low-latency reads and writes and preserve data when storage nodes fail.”
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
- Volume lifecycle
- Device interface
- Capacity
- Request rate and mix
- Latency
- Consistency
- Durability and availability
- Failure boundary
- Data lifetime and use
- Exclusions
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, attach, detach, and delete a volume.
- Read and write blocks through a VM device.
- Preserve acknowledged writes after one node or rack fails.
- Restore volume access after a VM or storage node fails.
Usually out of scope
- Snapshots and clones
- Concurrent access from multiple VMs
- Guest file systems
- Copies across availability zones
- Protection against a whole-zone failure
What interviewers ask about
- Write completion and node failure
- A successful write must survive a node failure. A lost reply leaves the VM unsure whether the write completed.
- Volume access after a failure
- An old VM and an old storage leader can both continue requests after a network fault.
- Data placement and repair
- Repair must restore protection without losing concurrent writes. Rack failures also consume spare capacity and network bandwidth.
- Latency under shared load
- Small requests require short queues. A busy volume or repair job can delay unrelated volumes that share storage nodes.
Common mistakes
- The candidate treats block storage as an object API and ignores the VM device contract.
- The design counts replicas but does not define when a write becomes durable.
- The design permits stale VM requests after a new attachment starts.
- The design reads from replicas without a freshness guarantee.
- The capacity estimate omits replicas, repair space, or replica network traffic.
- The repair process misses concurrent writes or consumes all capacity needed for client requests.
The bar by level
- Senior (L5/E5)
- Defines the acknowledgment point, quorum behavior, read freshness, and attachment fence. Handles retries, flushes, and replica repair during concurrent writes. Sizes capacity and network traffic.
- Staff (L6+/E6+)
- Separates consensus safety from attachment safety. Explains membership changes, partial attachment transitions, and recovery after uncertain writes. Quantifies repair exposure and spare capacity. Justifies replica group size and shared-resource limits.