{"slug": "how-google-stores-a-planet-the-gfs-explained", "title": "How Google Stores a Planet: The GFS, Explained", "summary": "Google's Google File System (GFS), introduced in a 2003 paper, underpins YouTube's storage by treating component failures as the norm. The design splits files into chunks distributed across many machines, with a master node managing metadata, a model that inspired the open-source HDFS and became the backbone of big data storage.", "body_md": "*Hello, I'm Maneshwar, and I'm building LiveReview — a blast-radius aware AI code review built for your business-critical systems. [Star us](https://github.com/HexmosTech/LiveReview/) to help devs discover the project, give it a try, and share your feedback to help improve the product.*\n\nRoughly 720,000 hours of video get uploaded to YouTube every day.\n\nCall it 1,000 terabytes. Tomorrow, another 1,000. The day after, another.\n\nTo hold that you need hundreds of thousands of machines with millions of drives spinning inside them.\n\nAnd here is the uncomfortable arithmetic: in a fleet that size, a drive is dying right now. Another one will die before you finish this post.\n\nYet not one second of anybody's cat video goes missing.\n\nSo how?\n\nThe obvious answer is money.\n\nGoogle is worth a few trillion dollars, so surely they just buy the good computers, the ones that do not break.\n\nWrong. That computer does not exist.\n\nPhysics does not offer an enterprise tier.\n\nAny machine you run will eventually fail, and once you have hundreds of thousands of them, failure stops being an event and becomes a background hum.\n\nThat is almost exactly how Google opened [the 2003 Google File System paper](https://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf): component failures are the norm, not the exception.\n\nWhat YouTube runs on today is a descendant of that design.\n\nThe open source clone, [HDFS](https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html), became the storage layer the entire big data industry stood on for a decade.\n\nLet's build it up from scratch, one broken assumption at a time.\n\nBefore we scale to a planet, look at your laptop.\n\nYour operating system ships with a file system whose whole job is organizing bytes on a disk.\n\nIt carves your storage into equal sized blocks. Usually 4 KB each.\n\nA 1 TB drive is therefore something like 268 million blocks, numbered from 0 all the way up.\n\nNow save `cat.png`, a 12 KB masterpiece.\n\nThe file system chops it into three 4 KB chunks and drops each chunk into whichever block happens to be free. Not neatly in a row. Wherever there is space.\n\nTo ever see your cat again, it records where the pieces went in an index. Every file is a row: here are its chunks, here are the block numbers.\n\nClick the file, the index is read, the chunks are gathered, the cat appears.\n\nHold that picture, because the rest of this post is the same idea with the blocks replaced by entire computers.\n\nNow try to store YouTube.\n\nThe biggest enterprise drive you can buy today tops out around a few hundred terabytes and costs about as much as a car you would be nervous to park outside.\n\nOne day of uploads already exceeds it.\n\nThe naive fix is to build one gigantic machine and jam drives into it until the ingest fits.\n\nTwo problems, and neither is subtle.\n\n**It is one power cable away from oblivion.** One outage, one fire, one clumsy technician, and every video ever uploaded is gone at once.\n\n**It does not scale.** There is a hard ceiling on how many drives you can hang off a single box, and a much lower ceiling on how many requests it can serve.\n\nSo take the local file system idea and stretch it. Instead of many blocks on one machine, use many machines.\n\nSeparate boxes, separate storage, separate buildings, separate power, talking over a network.\n\nA file comes in, gets chopped into chunks, each chunk lands on one of those machines.\n\nCall them **chunk servers**, because they store chunks and later serve them. Each one holds many chunks from many different files.\n\nThen one **master** plays the role the index table played. It knows every file, its chunk list, and the IP of the chunk server holding each chunk.\n\nA client asks for a cat video. The master hands back a list of chunks and addresses. The client fetches them itself and reassembles the video.\n\nNotice what the master is not doing: it never touches the video bytes. It hands out a map, then gets out of the way.\n\nThat single decision is why one master can serve thousands of machines without melting.\n\nNow kill a chunk server.\n\nA piece of the cat video just became unreachable, and a video missing a chunk is not a video. It is a buffering spinner with commitment issues.\n\nYour instinct says this is rare. And for one machine your instinct is right. A single server might fail once a year.\n\nBut run the numbers across a fleet.\n\nA year is about 31 million seconds. Spread one failure per server per year across a million servers and you get a failure roughly every 30 seconds, forever.\n\nIf your system needs every machine online to work, then your system is broken every 30 seconds.\n\nThis is the real GFS insight, and it is more philosophical than technical.\n\nYou do not build a reliable system by buying reliable parts. You build it by assuming the parts are garbage and designing around their funerals.\n\nThe first move is the obvious one. Keep more than one copy.\n\nEvery chunk is written to multiple chunk servers. Each copy is a **replica**, and the number of copies is the **replication factor**, which GFS sets to 3 by default.\n\nThe master now tracks, per chunk, the desired replication factor and every server holding a copy.\n\nOne server goes dark, the client just asks a different one. No drama.\n\nBut be honest about what this actually bought you.\n\nNothing was solved. Time was purchased.\n\nRun long enough and all three replicas of some chunk will eventually be dead at the same time, and that chunk is gone for good. Three copies of a decaying thing is still a decaying thing.\n\nYou need the system to notice the loss and react faster than the losses accumulate.\n\nEvery chunk server sends the master a **heartbeat**, say every few seconds. It means nothing more than \"still here.\"\n\nMiss a few in a row and the master declares that server dead. It strikes it from the replica list of every chunk it was holding.\n\nWhich means those chunks now have two replicas instead of three. Under target.\n\nSo the master picks a fresh chunk server that does not already hold that chunk and tells it to copy the chunk from a server that still has a good replica.\n\nThree again.\n\nThat loop, running constantly, is the whole trick.\n\nMachines die at a steady rate and re-replication runs at a faster rate, so the system sits in equilibrium while the hardware underneath it quietly rots.\n\n``` php\nflowchart TD\n    A[Chunk server heartbeats to master] --> B{Heartbeat received?}\n    B -->|Yes| C[Mark server alive, refresh chunk map]\n    C --> A\n    B -->|No, 3 misses in a row| D[Declare server dead]\n    D --> E[Remove it from replica list of every chunk it held]\n    E --> F{Replicas below replication factor?}\n    F -->|No| A\n    F -->|Yes| G[Pick a chunk server without this chunk]\n    G --> H[Copy chunk from a healthy replica]\n    H --> I[Replica count restored to 3]\n    I --> A\n\n    classDef decision fill:#f4d35e,stroke:#b8991f,color:#1a1a1a\n    classDef start fill:#e9ecef,stroke:#6c757d,color:#1a1a1a\n    classDef chip fill:#5ee6c8,stroke:#1f9c86,color:#1a1a1a\n    classDef bad fill:#ff9a5c,stroke:#c25c1f,color:#1a1a1a\n\n    class B,F decision\n    class A start\n    class C,G,H,I chip\n    class D,E bad\n```\n\nThe nice property here is that nobody pages a human at 3am for a dead disk. The dead disk is a routine input to a loop, not an incident.\n\nYou have probably spotted the hole.\n\nEvery replica of every chunk is tracked by exactly one master, and that master holds the state of the world in its memory.\n\nCongratulations, you built a fleet of disposable machines and then hung its entire availability off one very important box.\n\nThe fix rhymes with what you already did.\n\nThe master streams every change it makes to a backup master, which sits there receiving updates and doing absolutely nothing else. This is the **failover** master.\n\nBoth masters heartbeat to a health check service.\n\nClients never hardcode a master IP. They resolve a DNS name, say `master.internal`.\n\nWhen the health check service stops hearing from the primary master, it flips that DNS record to point at the failover, which already holds a near current copy of the state and simply takes over.\n\nThe pattern repeats at every layer: detect death with heartbeats, keep a warm copy, redirect traffic. Same song, different instrument.\n\nSo far everything has been about pulling data out. Downloads are pleasant because nothing changes underneath you.\n\nWrites are where distributed systems earn their reputation.\n\nHere is the scenario the paper cares about, dressed in something familiar.\n\nYou share a spreadsheet with your neighbours for booking apartment parking spots. Each row is a slot. Reserving means appending your name.\n\nSay the whole thing is one chunk, replicated across three chunk servers.\n\nYou want the spot. You ask the master for the chunk server addresses, get all three, and send your update to each of them. They confirm. All three copies are identical. Your car is parked. Beautiful.\n\nNow your neighbour wants the same slot at the same moment.\n\nYou both get the same three addresses. You both fire off your updates.\n\nChunk server A receives yours first, then your neighbour's. It appends you, then them.\n\nChunk server B receives your neighbour's first. It appends them, then you.\n\nThe three replicas of a chunk that are supposed to be byte identical now disagree about reality, and there is no way to tell which one is right.\n\nThe paper has a word for this. **Inconsistent.** Data that should be the same on every server is not.\n\nThe root cause is that each chunk server orders updates from its own point of view. It applies what it sees in the order it sees it, cheerfully unaware that its peers saw something else.\n\nLocal time is not global truth.\n\nThe fix is to stop asking three machines to independently agree and instead appoint one of them to decide. GFS calls that server the **primary** for the chunk.\n\nThe master chooses it, guarantees there is exactly one primary per chunk at any moment, and remembers who it is.\n\nNow the write flow changes shape:\n\nEvery replica ends up byte identical, no matter how many clients wrote at once.\n\nData flows to whoever is closest on the network. Order flows from a single point of authority. Separating those two is the elegant bit.\n\n```\nsequenceDiagram\n    participant You\n    participant Neighbour\n    participant M as Master\n    participant P as Primary replica\n    participant S as Secondary replicas\n    You->>M: Where is this chunk?\n    M-->>You: 3 addresses, plus who is primary\n    Neighbour->>M: Where is this chunk?\n    M-->>Neighbour: same 3 addresses, same primary\n    You->>S: push data (buffered, not applied)\n    Neighbour->>S: push data (buffered, not applied)\n    You->>P: write request\n    Neighbour->>P: write request\n    P->>P: assign serial order: You, then Neighbour\n    P->>S: apply in this exact order\n    S-->>P: applied\n    P-->>You: done\n    P-->>Neighbour: done\n```\n\nNote who does not appear in the hot path there. The master hands out a map at the start and then vanishes. All the heavy lifting is client to chunk server.\n\nEvery design decision above optimises the same thing: moving enormous amounts of data to enormous numbers of clients.\n\nIt is a bandwidth machine, not a latency machine.\n\nReading a 1 GB chunk stream is glorious. Reading one 200 byte record with a tight deadline is not what this was built for, and the designers knew it.\n\nThat is the actual lesson hiding inside GFS, and it generalises far beyond storage.\n\nYou pick the two or three properties your system genuinely needs, you optimise those relentlessly, and you take the others off the table on purpose.\n\nA system that refuses to choose is a system that is mediocre at everything.\n\nHere is the one the paper leaves you with, and it is worth chewing on before you look it up.\n\nImagine one file in your GFS cluster goes viral.\n\nA single post, a single video, and suddenly a large slice of all traffic is hammering the handful of chunk servers holding its chunks.\n\nThose machines are drowning while the rest of the fleet is idle. The paper calls this a **hotspot**.\n\nHow would you spread that load?\n\nThe [chunk size section of the paper](https://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf) has the answer Google reached for, and it is a smaller change than you would expect.\n\nGo read it. It is fifteen pages, it is written in plain English, and it is one of the few papers that reads like somebody explaining a thing they actually built rather than a thing they wanted funded.\n\nYour team's attention is limited, and the deluge of AI-generated code is making it harder to keep production secure and reliable without slowing you down.\n\nI'm building **LiveReview**, a blast-radius aware AI code review built for your business-critical systems.\n\nInstead of presenting every diff with equal emphasis, **LiveReview scores each change by blast radius — how far its impact reaches through your call graph — so you can focus attention where it actually matters.**\n\nSpend code review effort where business risk is highest — not spread evenly across every diff.\n\n⭐ Star it on GitHub:\n\nLiveReview is an AI code reviewer that scores every hunk of a diff by **blast radius**: how far a change reaches through your call graph, how much persistent state it touches, and how well-tested it is. A 3-line change to a shared auth check can outrank a 300-line UI tweak. Your team's attention goes to the highest-risk code first, not spread evenly across every diff.\n\n*LiveReview's Blast Radius & Review Priority scoring, live in the diff viewer.*\n\n| The exact math, not a black box | Visualize blast radius at a glance | Every factor that feeds the score | \n|---|---|---|\n\n**Here's the goal:**\n\n**Click below to try LiveReview with your codebase:**", "url": "https://wpnews.pro/news/how-google-stores-a-planet-the-gfs-explained", "canonical_source": "https://dev.to/lovestaco/how-google-stores-a-planet-the-gfs-explained-1fcp", "published_at": "2026-09-09 17:32:43+00:00", "updated_at": "2026-09-09 17:56:59.073886+00:00", "lang": "en", "topics": ["machine-learning", "ai-infrastructure"], "entities": ["Google", "YouTube", "GFS", "HDFS", "Maneshwar"], "alternates": {"html": "https://wpnews.pro/news/how-google-stores-a-planet-the-gfs-explained", "markdown": "https://wpnews.pro/news/how-google-stores-a-planet-the-gfs-explained.md", "text": "https://wpnews.pro/news/how-google-stores-a-planet-the-gfs-explained.txt", "jsonld": "https://wpnews.pro/news/how-google-stores-a-planet-the-gfs-explained.jsonld"}}