Segmenting, Five Dimensions

The strategy that shapes this platform is the one the paper spends most care on: rather than pick a single trade for the whole system, segment it into parts that each choose differently. The paper walks five dimensions, each with a named exemplar. Data: a shopping cart may be highly available and occasionally lose an update, while the billing record must be strongly consistent. Operation: PNUTS, Yahoo's serving platform, answers read-only requests always while some writes wait under a partition. Function: an application uses Chubby for coarse-grained locks (strict) beside DNS for naming (loose), two subservices with opposite trades. User: Craigslist splits its servers across an east-coast and a west-coast datacenter, so each region's users get proximity and each region's data stays coherent. Hierarchy: partition repeatedly, with better availability toward the leaves and less consistency toward the root, as the servers grow better connected the deeper you go.

The result is the sentence that is this platform's blueprint: the whole guarantees neither property, while every part guarantees exactly what it owes. Read as a global claim it sounds like a failure — the architects appear to have sacrificed both consistency and availability — but read per part it is precisely what the application needs. The paper is honest that a question stays open: it is not always clear what guarantees a given segmentation provides, or how the parts remain one system. This platform answers the second half concretely — the branded id of E2, minted once and carried unchanged across every segment, is the thread that makes the parts peers joined by an identity rather than layers whose guarantees average away. The tiers of E3 through E6 are these five dimensions, cashed.

Line the paper's exemplars up against the platform's tiers and the blueprint stops being an analogy and becomes a wiring diagram. Data is the cache-versus-ledger split: reads live in EchoStore, loose and fast; money lives in the ledger, strict and blocking. Operation is the read/write asymmetry inside a single tier: the memory answers a lookup as a caller-side hit that never enters the owner process, while a conflicting ledger write takes its row FOR UPDATE and waits — reads always, some writes not. Function is the tier boundary itself: the bus is an availability-first subservice, the ledger a consistency-first one, the store a bounded-staleness one, each chosen for what it does. User and hierarchy are the same dimension at increasing scale, and they leave the single machine — Craigslist's coasts become Fly regions and tunnel proximity, and the looser-toward-the-root gradient becomes edge-serves-last-known versus core-holds-the-row.

What the paper marks as unresolved — how a segmented system stays one system — is exactly the seam this course spends E2 on. Segmentation without a unifying thread is only a pile of services with incompatible guarantees; it becomes a platform only when a single identity crosses every segment unchanged. The branded id is that identity: minted once at the consistent core, gated at every ingress, carried outward to cache, log, and surface, so a value's life is one entity's life recorded once and read many places. The five dimensions are how the platform spends the CAP trade; the branded id is why spending it five different ways still yields one system rather than five.

The segmenting rule — choose the trade per part, not per system: the whole owes neither property, and each part owes exactly what it promises. The five dimensions are how a platform spends the trade in different currencies at once; the branded id of E2 is what keeps the parts a single system — peers joined by one identity, not layers averaging their guarantees away.