Design Rationale

Why build a centralized lock service instead of shipping a Paxos library that every application embeds? Why coarse-grained locks instead of fine-grained? Why advisory instead of mandatory? Each of these decisions reflects a deliberate trade-off -- and understanding them is more useful in interviews than memorizing the API.

Think first

Google could have shipped a Paxos library for every team to embed into their applications instead of building a centralized lock service. What are the practical problems with the library approach?

Why a lock service instead of a consensus library?

Concern	Consensus library	Lock service (Chubby)
Adoption curve	Every team must understand and integrate Paxos	Teams call Acquire() / Release() -- familiar lock semantics
Retrofit cost	Requires restructuring existing servers to participate in a protocol	Adding leader election takes a few lines of code
Quorum management	Each application must maintain its own set of replicas	Chubby provides a shared electorate -- clients need no quorum of their own
Event broadcast	Applications must build their own notification system	Chubby's built-in event mechanism notifies clients of master changes, lock updates, etc.

The net effect: a centralized service absorbs complexity that would otherwise be duplicated across every application.

Interview angle

"Why not just use a Paxos library?" is a common follow-up when you mention Chubby or ZooKeeper. The strongest answer: most teams don't need consensus primitives -- they need the outcomes of consensus (leader election, config storage, naming). A service wraps the hard part and exposes simple operations.

Why coarse-grained locks?

Chubby locks are meant to be held for minutes, hours, or days -- not milliseconds. Think leader election, not row-level locking.

Benefit	Explanation
Less load on the server	Lock acquisition rate is far lower than transaction rate
Tolerates brief outages	Clients holding coarse-grained locks are not significantly delayed by temporary server unavailability
Fewer servers needed	A modest number of lock servers can serve many clients

Coarse vs. fine-grained locks

Coarse-grained: one lock on a large resource (file, database table). Held for long periods. Fine-grained: locks on small resources (row, record). Held for milliseconds. Chubby is not designed for fine-grained use -- even brief unavailability would stall many clients.

Why advisory locks?

Chubby locks are advisory: holding a lock is neither required to access a file, nor does it prevent others from doing so. It is record-keeping that lets lock holders discover contention.

The alternative -- mandatory locks -- would make locked objects inaccessible to non-holders. Chubby rejected mandatory locks for three reasons:

1. Integration cost: enforcing mandatory locking on resources managed by other services would require extensive modifications to those services.
2. Debugging impact: mandatory locks prevent administrators from accessing locked files. Breaking the lock requires restarting the entire application.
3. Limited benefit: good practice already includes assertions like assert("Lock X is held"), so mandatory enforcement adds little safety.

warning

Advisory locks only work when all participants cooperate. A single misbehaving client that ignores lock state can cause data corruption. In interviews, mention this trade-off: advisory locks are simpler to integrate but rely on application-level discipline.

Why does Chubby need storage?

Clients often need to advertise the results of coordination to others:

• Publish the identity of an elected leader (leader election)
• Map aliases to absolute addresses (naming service -- replacing DNS)
• Announce data repartitioning schemes

Bundling storage into the coordination service means clients depend on fewer external systems. Chubby's storage needs are intentionally minimal: small objects (kilobytes) with simple create/delete semantics. For anything larger, use GFS or BigTable.

Why a Unix-like file system interface?

Chubby exposes a path hierarchy (/ls/cell/remainder-path) that looks like a file system because:

• It integrates naturally with existing tools built for GFS and other file systems
• Browsing and namespace manipulation work with standard utilities
• Casual users need minimal training

Only a very limited set of operations is supported (create, delete, read, write) -- this is not a general-purpose file system.

Chubby and the CAP theorem

Per the CAP theorem, Chubby is a CP system: it guarantees strong consistency (all reads and writes go through the master) and partition tolerance, but sacrifices availability during network partitions.

Scenario	Behavior
Stable master, no partitions	Very high availability -- common case at Google
Master fails	New master elected from replicas; service briefly unavailable
Network partition	Service becomes unavailable (consistency is never sacrificed)
More than half the replicas fail	Service stops operating

Under PACELC, Chubby is PC/EC: it chooses consistency in both partition and normal scenarios.

Interview angle

When classifying any system under CAP, state the trade-off precisely: "Chubby chooses CP because its primary use cases (leader election, distributed locking) require linearizable consistency -- serving stale data would be worse than being temporarily unavailable."

Quiz

Chubby uses advisory locks instead of mandatory locks. What would happen if a single misbehaving client ignores the advisory lock and accesses a shared resource without checking lock state?

Chubby would detect the violation and block the client's access.

Nothing would happen because advisory locks are just informational.

The misbehaving client could corrupt shared data because advisory locks rely on all participants cooperating -- there is no enforcement mechanism to prevent access by non-holders, which is a deliberate trade-off for simpler integration and easier debugging.

Chubby would revoke the misbehaving client's session.