Section 1: It's Not a Disk, It's a Fleet - Problem Understanding & Clarifications

Executive Summary: The prompt says "file system", and that word pulls candidates toward POSIX, inodes, block caches and NFS mounts. This section shows the first ten minutes of a better interview. Eight clarifying questions turn the prompt into something much narrower and much more buildable: a storage fleet of 1,000 commodity machines, where failure is the normal state of affairs, serving a few internal batch applications that we're allowed to change. Each answer removes a piece of classic file-system machinery. The section ends with a written list of assumptions and the sentence that shapes the rest of the design: build for the workload you actually have, together with the apps that run it.

The interviewer slides one paragraph across the table:

"Design a distributed file system, like Google's GFS, that stores multi-gigabyte files across a thousand commodity machines for batch workloads such as web crawling and MapReduce. Machines fail every day; the data must survive, and the cluster must deliver hundreds of gigabytes a second of aggregate read bandwidth."

Here's the trap. "File system" sounds like a disk that happens to be far away. A candidate who falls for it spends twenty minutes on directory inodes, cache coherence for client-side block caches, and how fsync should behave over the network. None of that is what the question is testing. The real design is one metadata brain that never touches data, 64 MB chunks, leases that order writes without running consensus on every one, an append that is atomic but may happen more than once, and a fleet that repairs itself every day.

Key Insight: The prompt contains two phrases that change the design: "machines fail every day" and "batch workloads". The first means failure handling is the main code path, not an edge case. The second means the clients are programs we can modify, not users with shell scripts. Together they let us drop most of POSIX.

The Clarification Exchange

Start by thinking out loud. A strong candidate asks questions whose answers visibly remove something from the design.

You: "Who are the clients? Arbitrary users and legacy tools, or a known set of internal applications?"
Interviewer: "Internal applications: the crawler, MapReduce jobs, indexing. Your company writes all of them."
What died: POSIX and the kernel mount. We ship a user-space client library and change the apps to use it. We rejected POSIX through VFS or NFS. The flip trigger is legacy tools that need to read this data, and even then we'd add an optional FUSE-style read shim on top. We wouldn't change the core.

You: "How big are files, and how many?"
Interviewer: "Multi-gigabyte, often bigger. Think tens of millions of files."
What died: optimizing for small files. I'll write down 30 million files averaging 1 GB, 30 PB logical. Stored as 1 MB files, the same 30 PB would need about 8 TB of master RAM (Section 3), which is why "large files only" is a requirement and not just a preference.

You: "What do reads look like?"
Interviewer: "Mostly large streaming scans. Small random reads exist, but they're rare."
What died: a client data cache. Nobody rereads a 1 GB stream, so we cache metadata only, with no coherence protocol. The flip trigger is a hot small file. Our answer there is a higher replication factor, not a cache.

You: "Writes: overwrites in place, or appends?"
Interviewer: "Overwhelmingly appends. Once a file is written it's mostly read, and random overwrites are rare."
What died: tuning for random writes. Appends are the operation we optimize. Overwrites still work, but they're correct rather than fast.

You: "How many writers per file at once?"
Interviewer: "Hundreds. Crawlers all feed one output file, and merges have many inputs."
This one adds work instead of removing it. Five hundred crawlers each append 1 MB records to /crawl/2026-11-02/hour-09.rec, about 100 MB/s in total. Client-side locks around write-at-offset would serialize them, so that option is out (Section 4 has the full argument). We need an atomic append where the system picks the offset.

Interviewer: "Doesn't that make consistency hard?"
You: "It does if I promise POSIX. I won't. I'll promise that each successful append lands atomically at least once, at an offset the system reports back. Readers skip padding and drop duplicates using a record ID. The crawler already puts a sequence number on every record, so the consumer can dedupe cheaply. Section 9 makes this precise."

You: "Latency or throughput?"
Interviewer: "Sustained bandwidth. A job that takes an hour doesn't care about a 50 ms read."
What died: tail-latency engineering on the data path. The target is about 500 GB/s of aggregate peak reads and at least 100 MB/s per stream, not millisecond responses.

You: "Scope: one cluster, or synchronous replication across data centers?"
Interviewer: "One cluster per data center. Cross-DC copies are the application's job."
What died: geo-replication and cross-DC consensus. We'll still say clearly what happens when a whole data center goes dark (Section 11).

You: "What hardware, and how often does it fail?"
Interviewer: "Commodity machines. You'll lose some every day."
Assume 1,000 chunkservers in 40 racks, ~2 machine failures a day and ~0.7 disk failures a day. What changed: RAID and "buy better servers" are out. Replication across racks, checksums and automatic re-replication are the core of the design.

Quick check before moving on: