Summary: Chubby

The big picture

Chubby solves one of the most fundamental problems in distributed computing: how do distributed nodes agree on anything? Leader election, configuration management, service discovery, distributed locking -- all of these reduce to consensus, and consensus is hard.

Chubby's contribution isn't algorithmic (it uses Paxos, which was already well-known). Its contribution is practical: wrap a complex consensus algorithm in a simple, familiar interface that looks like a file system with locks. This made distributed consensus accessible to every team at Google without requiring them to implement Paxos themselves.

The same insight drove Apache ZooKeeper, Chubby's open-source spiritual successor.

Architecture at a glance

Component	Role
Chubby cell	A cluster of typically 5 replicas, one of which is the master
Master	Handles all reads and writes; elected via Paxos
Replicas	Participate in Paxos consensus; take over if master fails
Clients	Maintain sessions with the master via KeepAlive (lease) messages

Key property: All writes go through Paxos (majority must agree). Reads are served by the master alone (fast, since the master is always up-to-date).

How Chubby uses system design patterns

Problem	Pattern	How Chubby uses it
Surviving master crashes	Write-ahead Log	All transactions logged before being applied
Ensuring write consistency	Quorum	Writes require majority acknowledgment (Paxos)
Preventing zombie masters	Split-brain (Epoch number)	Each new master gets a higher epoch; old master's requests are rejected
Managing client sessions	Lease	Time-bound session leases; expired sessions lose all locks and cached data
Preventing stale master access	Fencing	Lease expiry acts as soft fencing -- old master loses authority

Chubby's four roles

Role	How Chubby serves it	Who uses it
Leader election	Nodes compete for a lock; winner is leader	GFS master, BigTable master
Naming service	Consistent, instantly-updated file hierarchy replaces DNS	Google-internal service discovery
Metadata storage	Unix-style small file storage	BigTable schema, GFS metadata, ACLs
Distributed locking	Coarse-grained locks with sequencers	Cross-service coordination

Why coarse-grained?

Chubby is designed for locks held for hours or days (like "who is the leader"), not milliseconds (like "lock this database row"). Fine-grained locking at Chubby's scale would generate too much traffic and latency. If you need fine-grained locks, use a different mechanism closer to the data.

Quick reference card

Property	Value
Type	Distributed coordination / lock service
CAP classification	CP -- linearizable consistency via Paxos
Architecture	5-replica cell, single master
Consistency	Linearizable (reads always see latest write)
Data size	Small objects only (kilobytes)
Lock granularity	Coarse-grained (held for long periods)
Session management	Time-bound leases with KeepAlive renewals
Consensus algorithm	Paxos
Open-source equivalent	Apache ZooKeeper

Design Challenge

Design a service registry for microservices

You need to design a service registry for a platform with 500 microservices. Each service must discover the endpoints of services it depends on. Stateful services (databases, caches) need leader election. Small configuration data (feature flags, routing rules) must be stored consistently and pushed to services in real time.

Hints (0/4)

References and further reading

• Chubby paper -- the original 2006 paper
• Chubby architecture (video)
• Chubby vs. ZooKeeper (video)
• Hierarchical Chubby
• GFS paper
• BigTable paper