How the interviewer opens it
“Design a file transfer system like BitTorrent that lets people share very large files with many downloaders. Downloaders should also be able to send data to one another.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- Clients and environment
- Files and publication
- Scale
- Read:write mix
- Bandwidth
- Latency and completion
- Consistency and availability
- Durability
- Untrusted participants
- Scope boundaries
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Publish an immutable file and give downloaders a shareable identifier
- Discover peers and exchange pieces while a download is still in progress
- Verify received data and resume interrupted downloads
- Keep downloads progressing despite slow, disconnected, or unhelpful peers
Usually out of scope
- Content search and recommendation
- Payments, DRM, and copyright enforcement
- Editing a file in place
- Exact compatibility with the BitTorrent wire protocol
What interviewers probe
- Piece selection, parallelism, and the slow tail
- Fast individual downloads can produce a weak swarm if everyone requests the same early pieces. Conversely, blindly seeking rare pieces can delay startup, and a nearly finished download can stall behind one slow peer.
- Integrity, trusted metadata, and crash-safe resume
- Peers and discovery services need not be trustworthy. Hashes only protect the intended file when the expected metadata is anchored in something the user trusts, and crash recovery must not turn partial disk writes into advertised good pieces.
- Finding usable peers under churn and NAT
- A peer directory is only a list of candidates: entries go stale, many addresses are unreachable, and a hot swarm can overload discovery even though the file data bypasses it.
- Bootstrap capacity, upload incentives, and lasting availability
- Peer-to-peer distribution creates no bandwidth by itself. Initially only seeds have data; later, useful upload capacity depends on piece diversity, reachable peers, and whether users remain connected.
Common mistakes
- Designing a central object-download service with a cache and calling the clients peers.
- Spending the interview on tracker sharding while leaving the actual piece-exchange protocol undefined.
- Assuming a file hash verifies arbitrary partial data, or accepting untrusted piece hashes without a trusted root.
- Ignoring rare pieces, startup, and the final slow requests when choosing a scheduling policy.
- Treating peer disks as durable storage or assuming every advertised endpoint is reachable.
- Ignoring the aggregate upload bound and promising download speeds that the swarm cannot supply.
The bar by level
- Senior (L5/E5)
- Owns the client protocol and its failure cases: trusted metadata, rarest-first with startup and endgame behavior, bounded pipelining, crash-safe verification, stale discovery, and realistic NAT fallback. Quantifies why upload capacity limits the swarm and preserves seed-backed availability.
- Staff (L6+/E6+)
- Connects protocol policy to system-wide behavior: seed bootstrap and piece diversity, hot-swarm discovery, partition behavior, malicious-peer resource bounds, and the cost of restricted connectivity. States which availability and throughput promises are impossible without durable seeds or paid egress, and chooses the simplest architecture that meets the stated guarantees rather than defaulting to a DHT.