Architecture Synthesis

Architecture Synthesis derives where computation happens — deployment topology, data placement, consistency boundaries, recovery — from a system's service-level objectives, instead of choosing it from a catalog of styles. Derived, not chosen.

Most architecture books are one of two kinds: a catalog of styles and patterns you pick from and defend, or a physics of how replication, queues, and consensus actually behave. Neither tells you what to do on Monday. This is the missing third kind — a procedure.

The method runs on nine questions, translated into six architecture axes through a fixed set of rules, and closed with verification arithmetic: back-of-envelope capacity and availability math that checks a derived architecture against its own budget before anything is built. An architecture produced this way is never a one-time choice — it is re-derived whenever the answers change, on a greenfield system and on one you inherited, by the same procedure.

Part I builds the toolkit: an answer sheet whose questions each had to earn their seat, a ledger of what every architectural value provides and what it costs, the derivation procedure itself, and the verification gate. Small enough to apply from memory — a worksheet and a deck of reference cards.

Part II puts it on trial. The method re-derives one system on home ground, then derives four systems it does not control — Stack Overflow, Shopify, Discord, and a national companies registrar — blind, from their public commitments alone, with predictions registered in advance and graded in the open. The hits are shown. So are the misses, because a method that never fails is a parlor trick. The registered predictions, answer sheets, and grading rubrics are public in a replication kit, and counterexamples are invited.

A practicing architect can start here directly. A reader arriving from Process-First Design will recognize this as the next step.

Less art, more engineering — in the one decision that was still run on taste.