Section 6: Five Replicas and a Very Smart Client - High-Level Architecture

Executive Summary: A cell is five replicas in five failure domains. One is the master and serves every client request, reads included; the other four exist for durability and for electing the next master. Half the architecture lives in the client library: session, handle table, a strictly consistent cache and the event dispatcher. Three walks of orders-db fix the shape. A cached read of /ls/ny1/orders-db/master costs under 1 ms in-process. master-c's SetContents invalidates 24,000 caches (~1–2 s), then commits through a quorum of 3 in ~2–3 ms. An Acquire is another consensus write that moves the lock generation from 41 to 42.

The interviewer taps Section 5's two columns, replicated state and master memory. "Put the machines on the board. What does a client actually talk to?"

You: "One cell per data center, five replicas, one master doing all the talking. I'll draw it, then walk a read, a write and an acquire with orders-db."

The Cell on One Board

Every replica holds the whole database in RAM, about 1.3 GB against 256 GB servers, plus a local write-ahead log on SSD and snapshots every 30 minutes or 1,000,000 entries (D6). The five sit on distinct racks and power so that quorum is 3 and the cell survives 2 simultaneous failures (D4). Every hour a snapshot goes to object storage in another region, a store that does not depend on this cell, which bounds whole-cell loss at an RPO of 1 hour (D15). Proxies are dashed: a door Section 12 opens, not a day-one box.