# Design a block storage service like Amazon EBS: system design interview question

> Persistent VM volumes with durable write acknowledgments, safe access after failures, and low latency during repair.

Source: https://sysround.com/questions/design-block-storage-service-like-amazon-ebs
Updated: 2026-11-05


Difficulty: hard. Levels: Senior, Staff+.

## 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."

## 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

## 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 probe

### 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:** 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+:** 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.

Practice this question with an AI interviewer: https://sysround.com/practice/new?problem=cloud-block-storage


---
SysRound (https://sysround.com) is an AI practice tool for system design interviews. It has a voice or typed AI interviewer and a shared whiteboard. At the end, you get feedback on each skill and a model answer. The AI feedback can be wrong.