How the interviewer opens it
“Design a distributed file system for large files. It should support fast sequential access and continue service 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
- Data size
- Traffic and read-to-write mix
- Deployment
- File operations
- Visibility and consistency
- Latency and throughput
- Availability
- Durability and recovery
- Failure model
- Scope limits
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 a file and publish it after the writer closes it
- Read large files through sequential transfers
- List directories and delete files
- Maintain replicas and restore them after storage node failures
Usually out of scope
- Full POSIX semantics
- Random writes and append after close
- Replication between regions
- Detailed user access controls
What interviewers ask about
- File state and metadata
- The service must publish complete files without exposing partial data. Metadata failure must not create conflicting file owners or lose confirmed paths.
- Large file transfers
- Large transfers need sustained throughput. Partial writes, client retries, and stale writers must not change bytes that readers already trust.
- Storage node failures
- A failed node removes many replicas. Recovery competes with client traffic and exposes the remaining copies to further failures.
Common mistakes
- The candidate sends file bytes through the metadata service.
- The candidate chooses tiny chunks without estimating metadata size or request rates.
- The candidate protects file data from rack failure but leaves the namespace vulnerable.
- The candidate publishes partial files or permits stale writers to change closed files.
- The candidate treats every missed heartbeat as permanent data loss.
- The candidate describes repair without a bandwidth budget or limits on repair traffic.
The bar by level
- Senior (L5/E5)
- Defines durable acknowledgement, atomic close, retry behavior, and stale-writer protection. Calculates metadata size and repair bandwidth. Explains rack placement for both file replicas and metadata members.
- Staff (L6+/E6+)
- Defines failure guarantees across metadata, storage nodes, and racks. Explains safe failover during partitions and the limits of those guarantees. Balances repair deadlines, client throughput, and spare capacity. Controls node report volume and justifies when the namespace needs partitioning.