Section 8: Who Decides the Order? - Deep Dive: Leases, Versions & the Write Path

Executive Summary: Three replicas of chunk 0x7A3F must apply every mutation in the same order, with neither the master on the data path nor consensus per write. The master grants one replica a 60 s lease, and that primary assigns serial numbers. Each new lease bumps the chunk's version number, which is how a replica that slept through a change gets caught. Data travels separately along a pipelined chain: 1 MB reaches three replicas in about 1.1 ms instead of 2.4 ms. The honest cost: a dead primary's chunk can't be written for up to 60 s.

The interviewer points at the three replica boxes from Section 6. "Five hundred crawlers are writing into chunk 42. Who decides the order?"

You: "Not the master, and not a quorum protocol. The master decides who decides, once when the chunk gets busy, and that replica decides everything else."

Leases: Ordering Delegated, Not Agreed

The master grants a lease on a chunk to one replica, the primary, for an initial 60 s. While the lease lives, the primary extends it by asking on its regular HeartBeat, and the master can revoke it early (snapshot does exactly that in Section 9). So the global order is two-level: lease-grant order (master), then serial numbers (primary).

For 0x7A3F, cs-0412 (rack 12) holds the lease, and cs-0788 (rack 27) and cs-0153 (rack 05) are secondaries.

Interviewer: "Why not let the master stamp each write with a sequence number? It already has an op log."

You: "Then every mutation is a master RPC on the critical path, and master load scales with the write rate instead of lease grants, which stay ≤ 1,000/s. A busy chunk costs one grant, with one version bump, when it becomes busy; after that, extensions ride on HeartBeat for free."

Quick check before moving on: