What Backend Does Google Use? Languages, Frameworks and Storage
Google does not use a public backend framework such as Django, Rails, Spring Boot or Express for its main products. It writes services against internal libraries instead.
A framework is a set of ready made parts that shape how you write a service. Google built its own set, because its traffic and storage needs arrived before most public frameworks existed.
Four languages carry almost all of it: C++, Java, Go and Python. Search, Ads, Maps and Gmail are built from many small services in those languages.
| Layer | What Google uses | Public version you can use |
|---|---|---|
| Languages | C++, Java, Go, Python | Same four |
| Service calls | Stubby, the internal RPC system | gRPC |
| Data format | Protocol Buffers | Protocol Buffers |
| Wide table store | Bigtable | HBase, Cassandra |
| Global SQL store | Spanner | Cloud Spanner, CockroachDB |
| File storage | Colossus | HDFS, object storage |
| Analytics engine | Dremel | BigQuery |
| Cluster manager | Borg | Kubernetes |
| Build tool | Blaze | Bazel |
The languages, and where each one is used
C++ carries the parts where speed and memory control decide the cost. Search serving and core storage systems sit here.
Java runs many large backend services and much of the Android tooling. Go is common in networking, infrastructure and newer services.
Python is used for scripts, data work, machine learning and internal tools. JavaScript and TypeScript sit on the front end, not the backend.
How the services talk to each other
Every Google product is split into many services. Those services call each other with a remote procedure call, which means one service runs a function inside another.
Internally that system is called Stubby. gRPC is the open source version of the same idea, and anyone can use it.
The messages are Protocol Buffers. This is a compact binary format with a schema, so it is smaller and faster to parse than JSON.
Where the data lives
Google published papers on most of its storage systems, so the designs are public.
- Bigtable. A wide table store for very large key based workloads. It holds data for products such as Search and Maps.
- Spanner. A relational database spread across regions that still supports transactions and SQL.
- Colossus. The distributed file system underneath the rest. It replaced the older Google File System.
- Blobstore. Storage for large objects such as images and video.
- Dremel. The query engine for analysis over huge read only datasets. BigQuery is the product built on it.
There is no single database. Each service picks the store that matches its access pattern.
Where the code runs
Google does not hand a machine to a service. A cluster manager called Borg places jobs on machines and restarts them when a machine dies.
Borg runs work in containers, which package a program with everything it needs. Kubernetes was built by Google engineers after Borg, and it is the public version of the same approach.
The result is that no service depends on one machine staying alive. Capacity is added by asking for more instances.
How the code is written and built
Almost all Google code lives in one huge repository, called Piper. Teams share libraries directly instead of publishing packages to each other.
The build tool inside Google is Blaze. Bazel is its open source release, and it is what most people outside Google can use.
Every change goes through code review before it is merged. Tests run automatically on the change.
What this means in a system design interview
You are not asked to name internal Google tools. You are asked to make the same choices those tools make.
The useful pattern to learn is the split: small services, one clear data store per job, and a way to run many copies of everything.
- Pick a wide table store for very large key lookups, and a relational store when you need transactions.
- Put a queue between services when the writer must not wait for the reader.
- Cache reads that are expensive and repeated.
How to Prepare
- Learn the building blocks before the case studies. Grokking System Design Fundamentals covers storage, caching, queues and load balancing.
- Practise full design questions. Grokking the System Design Interview works through the designs Google style interviews use.
- Know the language question too. See what coding language Google uses and which language is best for a Google coding interview.
- Read the real papers once. Bigtable, Spanner, Borg and Dremel each have a public paper, and the trade offs in them come up in interviews.
- Check the level you are targeting. A Google L5 system design interview expects depth on these choices.
GET YOUR FREE
Coding Questions Catalog
$99
$197
$72
