Back to Writings
Published: August 21, 2026 • By Harsh RB

How Google Actually Works: Moving Beyond the Single-Machine Mindset

How Google Actually Works: Moving Beyond the Single-Machine Mindset

A deep dive into Google's planet-scale distributed infrastructure from Borg and Colossus to Spanner, Jupiter, and TPUs and how it survives constant failure through resilient abstractions.

How Google Actually Works

Moving Beyond the Single-Machine Mindset

A deep dive into Google’s planet-scale infrastructure, exploring how distributed systems like Borg, Colossus, Spanner, and TPUs operate seamlessly behind elegant abstractions.

As someone who spends a lot of time developing full-stack web applications and deploying them on platforms like Vercel, it is easy to think of the internet as just a client and a server. Even when working on machine learning workflows, I usually just think about the API keys and the immediate compute I am using. But what happens when you have to scale that to billions of users? How does Google do it?

I recently dove deep into Google’s infrastructure, and it completely changed my perspective. The biggest realization? Google is not one giant supercomputer. Google’s infrastructure is actually a massive collection of distributed systems. The core problem they had to solve was not just building a faster computer, but building a system that survives constant hardware, network, and software failures. At their scale, failure is just a normal operating condition.

I have documented this architectural deep dive in my research paper: How Google Actually Works: Systems Architecture for Planet-Scale Computing.

Here is a breakdown of how the different pieces of their infrastructure fit together.

The Compute Pool: Borg

When deploying a standard web app, we usually pick a specific server or instance. Google takes a completely different approach using a cluster-management system called Borg.

  • Borg turns tens of thousands of machines into a single resource pool.
  • It schedules hundreds of thousands of jobs and manages resource isolation.
  • If a machine running a workload dies, Borg detects the failure and schedules the work on a new, healthy machine.

Rethinking Storage: From GFS to Colossus

You cannot store Google’s data on a single hard drive.

  • Google originally built the Google File System (GFS) for large-scale data processing over inexpensive commodity hardware.
  • As workloads grew, they evolved to Colossus, which uses a distributed metadata model to improve scalability.
  • Colossus separates metadata operations from bulk data movement, which prevents the creation of a centralized throughput bottleneck.

Managing Structured Data: Bigtable and Spanner

For structured data, Google built specific distributed databases.

  • Bigtable is a distributed storage system for structured data that scales across thousands of commodity servers.
  • Spanner is a globally distributed relational database that provides strong external consistency.
  • Spanner uses an API called TrueTime, which explicitly models time as an interval of bounded uncertainty rather than a perfectly synchronized timestamp.

The Network: Jupiter and B4

The network is just as critical as the compute and storage.

  • Inside the data center, Google uses a multi-stage Clos-based architecture called Jupiter, which provides massive aggregate bandwidth and multiple paths.
  • Across their wide-area network connecting sites, they use B4, a software-defined network that allows them to program traffic according to application-level priorities.

AI Infrastructure: Tensor Processing Units (TPUs)

I have been provisioning API keys in Google AI Studio and exploring machine learning platforms lately, and learning about the backend hardware powering these models was fascinating.

  • Google uses custom accelerators called Tensor Processing Units (TPUs) for their machine learning workloads.
  • The TPU v5p system features 8,960 chips per Pod and utilizes a 3D-torus interconnect topology.
  • Because AI models require massive data exchange, the network interconnect between these TPUs is just as important as the chips themselves, turning the network into part of the computation.

Conclusion: The Power of Abstraction

Looking at all this, the most important lesson for any software engineer is about abstraction. Google’s real achievement is not eliminating complexity; it is containing that complexity behind abstractions so that developers can simply focus on building the application. It is a huge step up from building student campus platforms or deploying small preview environments, but the fundamental principles of handling data and compute efficiently remain the same.