How I ended up rebuilding Google's file system because I was bored

I was blog-scrolling one day and came across an article, "10 must-read white papers for every software engineer" by Dev Cookies. I was bored, so I clicked. I skimmed the list, and then I had an idea. A bright idea (bright being very relative here): what if I read these papers one at a time and tried to rebuild each one, badly and on a much smaller scale, just to actually understand them?

And once that idea landed, it was an itch I couldn't get rid of.

First on the list was the Google File System. I read it once and almost quit on the spot (because… why would I do this to myself?). Then I got to the parts about concurrency and coordination between machines, and remembered my friends John and Dara would not stop talking about gRPC. One problem: I'd never written a line of Go.

So before I could "Go" through GFS, I had to go through Go.

A weekend later I had mini-GFS: a tiny, working, self-healing distributed file store, and a much better appreciation for the fifteen pages I'd nearly skipped. Here's what I built, what I got right, and the one embarrassing thing I got wrong that taught me the most.

So what did I actually build?

Three Go binaries that talk to each other over gRPC:

• a master that remembers which files exist, which chunkservers hold them, and which servers are still alive;
• a bunch of chunkservers, dumb bags of bytes that store blobs and send a heartbeat every 5 seconds so the master knows they're breathing;
• a client that's also a little web app, so you can drag a file into your browser and watch the whole thing happen.

Upload a file and here's the ride it goes on: the client generates a random AES-256 key, encrypts the file with it, then encrypts that key with an RSA public key. The chunkservers never see anything but ciphertext, and the master stores the wrapped key but can't read your data either. Then the master picks two live servers, the client writes the encrypted blob to both, and you get back a UUID.

The part I'm actually proud of: it heals itself. Kill a chunkserver mid-run and the master notices within about 15 seconds, finds a surviving copy of every chunk that server was holding, and tells another server to pull it over. No data lost. Watching that happen in the logs the first time was the single best moment of the project.

And the part that humbled me: I called it a file system and then realized I'd skipped the one thing GFS is famous for. More on that in a second.

What I got right vs. what the paper actually says

The fun of rebuilding a paper is discovering exactly which corners you cut, and why the original didn't cut them. Here's the honest scorecard:

• Chunking. Real GFS splits files into 64 MB chunks; mine stores one file as one chunk (≤64 MiB). Lesson: chunking is the point, not a detail.
• Writes. Real GFS has the client write to a primary replica that pipelines to the others via a lease; mine just fans out to all replicas itself. No primary, no lease, no mutation ordering.
• Durability. Real GFS keeps an append-only operation log plus checkpoints; mine rewrites the whole metadata.json on every change. An honest shortcut.
• Encryption. Real GFS has none; mine does AES-256-GCM per file with RSA-wrapped keys, all client-side. Here I went beyond the paper.
• Self-healing. Real GFS re-replicates chunks lost to dead servers, and this one I built faithfully. The part that's actually GFS.

Two things I'll happily brag about:

• The re-replication genuinely works. Heartbeat, detect a dead server, pull a fresh copy from a survivor. Kill a node and the cluster rebuilds itself.
• The encryption design is legitimately nice, and it's mine, not GFS's. The master stores the RSA-wrapped key but can never read your data. Zero-trust storage nodes, for free.

What I got wrong (and why it was the best part)

I called this thing a file system and then quietly skipped the one idea GFS is built around: chunking. Real GFS slices big files into 64 MB chunks and scatters them across the cluster. That's what lets it store files bigger than any single disk, and it's the number everyone remembers from the paper. My version stores each file as one blob and calls it a day.

Here's the thing though: building it without chunking is exactly how I finally understood what chunking is for. You don't feel the need for an abstraction until you've lived without it. The paper had told me "64 MB chunks" on page one; it took writing the naïve version for it to actually mean something.

Roadmap: turning mini-GFS into something that earns the name

Ordered by how much each one will actually teach me, not by how hard it is:

1. Actual chunking. The big one. Split files into fixed 64 MB chunks client-side, give each its own handle, and let the master track an ordered list of chunks per file. This alone changes everything downstream: reads and writes become per-chunk, and files can finally outgrow a single machine. The master already stores a list of chunks per file; it just always has length one today. The data model is ready; the client isn't splitting yet.

2. Streaming instead of "load the whole file into RAM." Right now the client reads the entire upload into memory (that's where the 64 MiB ceiling comes from). With real chunks, I can stream chunk-by-chunk over gRPC and drop the size limit entirely.

3. A primary replica + leases. Today the client writes to every replica itself, in no particular order. Real GFS has the master grant a short lease to one replica, the "primary", which decides the write order and forwards to the others. That's how GFS keeps replicas consistent under concurrent writes, and building it is the only way I'll really get why the lease exists.

4. An operation log instead of rewrite-the-whole-file. The master currently re-serializes all its metadata on every change. GFS uses an append-only operation log plus periodic checkpoints so it recovers fast and never loses a mutation. Cheaper, safer, closer to the paper.

5. Checksums on the chunkservers. AES-GCM already catches tampering in transit, but a real chunkserver verifies its own blocks against stored checksums to catch silent disk rot. Small change, very GFS.

Numbers 1 and 3 are the ones that'll teach me something. The rest is polish.

Onto the next one

One paper down, nine to go. If nothing else, I now know that "distributed" is a word that hides an enormous amount of work, and that reading a paper and building the paper are two completely different sports.

Shout out to John and Dara for not shutting up about gRPC. Turns out you were right.

PS: It’s fully open source, you can check the code here.