A chat platform’s busiest channel goes hot: a hundred thousand people watching one conversation, every one of them pulling the same recent messages from the same database partition. Concurrency climbs, latency cascades, the partition melts. The team’s first instinct is the industry’s first instinct — shard harder — and it cannot work, structurally: those reads want one channel’s rows, and one channel has one home no matter how many shards exist. What contains the melt is a thin layer in front of the store that notices a hundred thousand identical in-flight reads and sends the query once. The fix costs a fraction of the resharding project it replaced, and no catalog of architecture styles contains it, because it lives below the altitude catalogs describe: it is a fact about what mechanisms can contain.
This chapter is a book of such facts. The method’s geometry has three spaces: the demand space Chapter 2 produced, where commitments live as numbers with scopes; the position space Chapter 4 will walk, where every architecture is a vector on the six axes; and between them the selection space this chapter maps — what each position on each axis provides, through which mechanism, at what always-on cost. Classic architecture literature works in this middle space with quality-attribute vocabulary and drowns, because “-ilities” are not decidable. The catalogs skip the space entirely, jumping from demands to named styles by narrated judgment. The derivation becomes checkable at exactly the moment this middle space becomes explicit: selection is the cheapest vector whose capability envelope contains the demands — a sentence that means nothing until capabilities and costs are written down, and everything after.
The written-down version is the ledger. Its discipline, before its contents:
- Entries are mechanism physics — what a projection costs, what a queue absorbs, what quorum commit cannot avoid (the round trips a write pays to reach agreement across a majority of replicas). They are never compatibility rules between styles; interactions surface inside derivations, as contrast.
- Values are atomic. “Hybrid” and “mixed” are compositions produced by scope splits, priced as parts plus the boundary between them.
- Values apply at demand scope. Event-source one data class; separate one read path; extract one component. A value applied wider than its demanding scope is unforced cost — a definition of technical debt this book will use repeatedly.
- Costs are always-on. A mechanism bills for existing — operation, evolution, failure modes — whether or not the capability is exercised this quarter.
- Containment is a claim about a bound. A value or mechanism contains a demand when it holds the demand’s stated number — at its percentile, over its window, under its declared shape — at the demand’s scope, at the mechanism’s always-on cost. The claim is exactly as probabilistic as the bound it serves: a replica pool contains a read-volume demand at P95 and at a named staleness, not absolutely; an admission gate contains a contention demand up to its configured arrival rate and not beyond. Whatever assumptions the bound carries, the containment claim inherits — which is why every containment survives or dies at the exit gate’s arithmetic rather than on the ledger’s word.
Demand shapes: what kind of pressure is this?
Before any axis question, a load answer must declare its shape, because shape selects the containing mechanism family — and the industry’s standing error is buying volume mechanisms for contention problems. One diagnostic separates them: would a second copy help?
Volume says yes. Sustained magnitude spreads across copies, caches, shards; volume is the shape capacity answers.
Contention says no. Many actors, one record — one seat at the on-sale moment, one hot channel, one flash-sale inventory row. The contended record has one home regardless of fleet size, so containment means governing arrivals: admission control and fair queueing on the write side, request coalescing on the read side, or reshaping the operation so the conflict cannot occur. Sharding a contention problem buys hardware and keeps the melt.
Burst is a peak with a tolerable settling delay, and its mechanism is a buffer: the queue absorbs what the deepest dependency never sees. The definition contains its own test — a peak that must be served synchronously is volume at the peak number, and calling it a burst just moves the failure two weeks later.
Deadline is “finish inside the window,” a batch shape: payroll by the 25th, filings by year-end. Deadlines are answered by windowed throughput and resumable work, and latency mechanisms are irrelevant to them — with the Chapter 2 triage in force, because most deadlines in a sheet bind the requester’s clock and press nothing at all.
The shape taxonomy is deliberately open at the front. New workload families arrive wearing new clothes and old shapes: a GPU serving one large model is contention (one resource, many claimants — admission and batching, never naive replication of what cannot be copied cheaply); token streaming is the streaming substrate’s shape at session scope; a training run against a cluster deadline is deadline-shaped with checkpointing as its resumable-batch mechanism. The diagnostic questions do not change; the examples will.
Containment rungs: the moves that are free of architecture
Some mechanisms contain demands without moving any axis, and pricing them first is what keeps derivations minimal. The rule that governs them: a tier that owns no business logic and no data of record — a load balancer, a cache, a coalescer, an admission gate — is a containment mechanism, invisible to the vector. Systems accrete many such tiers; their architecture does not change thereby, and a vector that counted them would overstate every real system it described.
Rung zero is hardware. Sizing the cheapest position — more memory, more cores, the whole working set in RAM — contains volume and latency pressure with zero new mechanisms, which by this chapter’s selection logic makes it the first bid on every containment, and one of the great engineering cultures of the web ran on that rule as an explicit company value. The rung has a ceiling, and the ceiling is economic rather than technical: it stops when the working set or the write rate outgrows what one box’s price curve buys, and past that point every further dollar purchases less than the mechanism it was avoiding. The price curve itself is substrate-dependent, and the rung must be priced on yours: on owned metal the curve is gentle and the rung famously long; on cloud pricing it steps at instance-size cliffs, bills egress separately, and caps out earlier: the same rule, run against a different ledger row, sometimes returning a different answer. What does not change is the rule’s position: first bid, priced before any axis moves.
Read pressure climbs a fixed chain: cache → coalescing → replicas → projections. Each rung contains a different shape: repeated reads of hot values; concurrent identical in-flight reads; same-shape read volume past one node; and only at the top, reads whose shape itself diverges from the write model. The top rung is the axis move. Everything below it is not, and the chain’s discipline is that you climb it rung by rung, stopping where your citations stop. Part II grades this chain against three industrial systems that stopped at three different rungs — each stop forced by that system’s answers — and against the fashion that begins at the top rung by default and calls it best practice.
The axes
Six axes, each with atomic values, each value a provides / mechanism / costs entry — and the entry’s three fields are exactly the joints the procedure will articulate: prune strikes a value when provides cannot meet a correctness demand; press tests demands against what provides holds at scope; resolve counts mechanisms; and costs is the always-on bill the whole selection minimizes. A richer schema — requires columns, excludes columns — would add nothing the three fields do not already encode: exclusion is the absence of a provides, and a prerequisite is a mechanism, priced like any other. What follows renders the ledger at chapter altitude — the full entries live in the reference cards.
Deployment topology — single deployable / multiple deployables / unified runtime / serverless. This axis prices two countables, kept apart because its costs split between them: the artifact, versioned and released as one — release coupling and the delivery plumbing bill here — and the runtime unit, an instance group shaped and scaled as one — scaling shape and runtime blast radius bill here; the network inside a crossing bills to neither, only to the boundaries the composition substrate actually crosses, and is largely pre-paid where the substrate is already event-based. The single deployable — one artifact, identical instances — provides in-process calls on every internal path, one operational surface, and one composition in production — the composition you test is the composition that runs — at the cost of whole-system blast radius and whole-unit scaling; its modular form adds ownership boundaries at zero deployment cost, which is the fact that dissolves most “we need services” pressure once Chapter 2’s decomposition has run. Its role-selective form — the same artifact, handlers or process classes enabled per instance group, a form with decades of record as web-and-worker processes from one codebase and database node roles from one binary — buys back per-role scaling envelopes and inter-pool blast isolation with no second artifact, at the price of the activation machinery becoming a mechanism of its own: role configuration, per-role capacity, knowing which instance runs what. What no single artifact buys is release independence: one artifact is one train, disabling a handler at runtime is a kill-switch — recovery machinery, not a cadence — and waking a dormant handler on a running instance takes the isolation back, one process envelope now shared. The train itself is a bill that grows with the codebase — one build, one test gate every team’s merge waits behind. Module-aware builds and affected-only test selection contain it a long way, a containment rung of its own; what remains when they cap out is a cadence demand, pressing the axis through the answer sheet rather than around it. Multiple deployables provide what only artifact multiplicity can: independent release cadence, independent toolchains and dependency evolution, blast isolation that holds at deploy time too. Their cost is a network inside every crossing — a latency floor, partial failure as an internal concern, consistency across the boundary decaying from transaction to protocol — paid in full where calls are direct, and mostly pre-paid where the substrate move already put a broker between the parts. Their second cost is the delivery plumbing, multiplied: each artifact is its own pipeline, its own release process, its own dependency stream to keep patched — and its own row in a version matrix, because independent cadences mean production runs a mixture of versions through every rollout window. The composition that was tested is no longer the only composition that runs; cross-artifact compatibility stops being an event and becomes a standing bill — contract tests, deprecation windows, the N-by-M pairs. The unified runtime holds packaging open — one-or-many decided at deploy time without rewiring — at the cost of a platform dependency; the role-selective form is its hand-rolled ancestor, and what the product adds is the same deploy-time freedom for direct-call composition. The platform class is young; the pattern is not. This book’s author builds one such runtime, disclosed here precisely so the derivations can be checked for favor: none requires it. Serverless provides per-invocation scaling to zero at the cost of cold-start tails and per-invocation pricing that crosses over against sustained load.
Composition substrate — direct calls / event-based / streaming. Direct provides the lowest latency and read-your-effects immediacy at the cost of temporal coupling: the callee must be up now, availability multiplies down the chain, bursts arrive unbuffered at the deepest dependency. Event-based buys temporal decoupling, burst absorption, and fan-out, and its price deserves stating in full because it is so often paid unknowingly: propagation lag on every consumer view, delivery semantics that force idempotent consumers, ordering only per key — and the between-steps state becomes durable, named, and operated. Streaming provides ordered, replayable, consumer-paced consumption for the one data class whose volume earns a partitioned log, at the cost of partition-key design becoming load-bearing.
Read/write model — unified / separated. Unified provides read-your-writes for free and zero projection machinery; the entire containment chain above lives inside this value, which is why it survives far more load than its reputation suggests. Separated provides independent scaling and shape for one read path, through projections, at the cost of a staleness window, machinery to build and backfill, and dual schema evolution — a price worth paying exactly when a read path carries its own contractual target and its own shape, and worth refusing otherwise.
State storage — current-state / event-sourced. Current-state provides the read as the state; paired with an audit log written in the same transaction it answers every who-what-when question, which is why Chapter 2’s three-way decomposition guards this axis. Event-sourced provides genuine replay — state at any past moment, why under that moment’s rules — at a cost that compounds forever: every read a projection, event schemas versioned for life, unbounded growth, and a model the team must learn to think in. The value is real and the demand that earns it is rare; the ledger’s job is keeping the two matched. And one statutory demand runs against this axis’s expensive value: erasure. Where the law requires that personal data become irrecoverable, append-forever machinery meets its counter-demand, and the containment mechanisms are their own small ledger row: scope exclusion first (keep personal data out of the immutable stream, referenced from a mutable store), crypto-shredding (encrypt per subject, erase by destroying the key), tombstoning where the store supports honest deletion. Replay-required and erasure-required on the same data class is a genuine contradiction with a statutory source: the derivation surfaces it and hands back the menu, exactly as Chapter 8 shows.
Persistence configuration — single shared / distributed shared / sharded / per-component / polyglot. The single shared store provides cross-component transactions for free: strict consistency, delivered by fifty years of engineering, at the cost of a shared ceiling and shared blast radius. The distributed shared store holds a unique position: it is the only value in this ledger that provides strict transactions across regions with zero data loss on regional failure, and its price is physics, a write floor of cross-region round trips times quorum, which no vendor tunes away. Sharded provides write scaling past one node when the demand set carries a natural partition key; its cost is that cross-shard transactions effectively cease and the key becomes load-bearing. One escalation deserves its own entry: when volume sharding compounds with blast-radius isolation — one tenant’s disaster must not touch another — the shard boundary widens to the full stack, a complete isolated instance of the system per shard: cells. The cost is the whole stack duplicated per cell and cross-cell features structurally forbidden, and the prohibition is the value working, as Part II’s hundred-plus-cell example shows. Per-component and polyglot provide independent evolution and stores shaped to their data, at the cost of transactions across components decaying to protocol and one operational competency per store technology.
Recovery — compensate-by-inverse / degrade-and-continue / design-out — the axis with no null, because every effectful operation must answer it, and the axis whose inputs are Chapter 2’s domain-shape facts rather than anyone’s preferences. It is also the axis a careful reader flags as the odd one out: the other five position structure; recovery prescribes behavior under failure. The asymmetry is real, and the seat is earned under the same criterion as the rest — systems with different recovery answers differ structurally before any technology is chosen: compensation paths are real code with real tests, design-out reshapes the domain model itself, degradation demands bounded windows with visible state. The exit gate’s failure column consumes exactly this axis’s choices, per operation. An axis is a dimension along which systems must differ; nothing requires the dimensions to be the same kind of thing. Readers of this book’s companions know these three as the recovery triple: BER, FER, and design-out; the classes are identical, and the short names remain the series’ compact notation (backward recovery compensates, forward recovery degrades and continues) while the long names carry the prose, because a name that says what you do beats one you have to look up. Compensation provides restored consistency where the domain offers an inverse, at the cost of compensation paths that are real code with real tests, and where the inverse must be built, it is a use case of its own with its own targets. Degrade-and-continue provides forward progress where staleness or decay is tolerable (defaults, queues-for-later, values that expire) at the cost of degraded windows that must be bounded and visible. Design-out provides the strongest guarantee available anywhere in this book: the failure class stops existing — idempotent writes, commutative operations, append-only records, a structural constraint that makes the double-booking unrepresentable — at a price paid once, in the shape of the model. Where design-out is available it embarrasses the alternatives, and checking for it first is a standing rule.
The boundary has a price
Compositions appear throughout the values above — separated at one path, sharded at one scope — and every composition contains a boundary, which the ledger prices like any mechanism. A scope split pays: a contract, versioned and negotiated evermore; consistency across the seam decaying from transaction to protocol; a translation layer answering to both sides’ changes; an operational seam where deploys, monitoring, and incidents must be correlated, and for persistence splits, one durability story per store. This entry cuts both ways. It is why splits must be forced rather than fashionable, and it is why, when Chapter 4’s conflict rule finds pressures at genuinely different scopes, splitting at that boundary is honest engineering: the price buys separation the demands actually require.
The selection rule
The ledger closes with the rule that consumes it, and the rule is short:
- Start at the null vector — the cheapest value on every axis: single deployable, direct calls, unified reads, current-state, single shared store.
- Move only when a demand is uncontained — and check the rungs before conceding that it is.
- For prune-mode demands, test scope exclusion first: narrowing where the demand applies can beat hardening any axis — Part II contains a payment-card mandate contained by routing card data around the entire system, which thereby never entered the mandate’s scope at all.
- Among containing values, prefer the one introducing the fewest new mechanisms — each is an ongoing bill, and mechanism-counting is how “cheapest” stays honest when prices resist arithmetic. This is the precise sense of Chapter 1’s “arithmetic”: not that costs add like numbers — they do not — but that the comparison is mechanical, counting mechanisms rather than weighing taste.
- Apply the value at the narrowest scope that contains the demand.
Why six axes and not sixteen? The same criterion that governed the questions, mirrored: an axis earns its seat only if systems with different answers must differ structurally along it before any technology is chosen. Candidates that fail collapse into technology choices — products, languages, clouds — which matter enormously and are not architecture. The strongest rejected candidate deserves its rejection shown, because it is the one every reviewer proposes first: security topology (trust boundaries, tenancy isolation, authentication placement). Run the criterion: the demands it carries route through axes that already exist: tenancy isolation is blast-radius isolation and arrives at cells; data-protection mandates are prune-mode external constraints and arrive at scope exclusion or erasure mechanisms; what remains after those routings (which gateway, which identity product, mTLS or tokens) is mechanism and technology choice, real work that no structural position decides. Two systems with different security answers do not differ along a seventh axis; they differ along the six, plus their technology sheet. The other candidate every reviewer proposes is team topology — the org chart, Conway’s Law offered as a seventh axis. Run the criterion: team ownership is a real pressure, and the deployment entry above already contains it — module boundaries at zero deployment cost, with a genuine split forced only when release cadences diverge, a demand already on the sheet, pressing an axis that already exists. A team structure that splits a system no answer divides is not a missing dimension; it is an unforced position, Chapter 9’s subject. Two systems with different org charts and identical answers derive the same vector; the org chart that overrode the derivation left debt behind, not a new kind of structure. The count is an output here exactly as it was in Chapter 2: the criterion is the theory, six is its current result, and the result is empirical — earned against the derivation record, not proven from first principles. A completeness proof for a design space is not on offer, here or anywhere. If a future derivation finds a security or organizational demand that presses nothing existing and forces structure of its own kind, the criterion outranks the count here too. That is what it is for. The six above have survived every derivation this book runs, one of them by surviving an audit this book nearly retired it with; Part II tells that story against a live system, because an instrument’s near-death is evidence about the instrument.
Demands from Chapter 2, capabilities and costs from this one. What remains is the procedure that walks them against each other — including the moment two demands press one axis in opposite directions, which is where most methodologies wave their hands and this one runs a test.
Instruments introduced: the three-spaces model · the ledger and its discipline · demand shapes and the second-copy diagnostic · containment rungs and the read chain · the six axes’ values · the boundary cost · the selection rule · the axis-membership criterion.