System Design
How to reason about boundaries, ordering and failure before writing code.
Overview
System design here is mostly about four things: identifying the decisions everything else is downstream of, choosing the order in which operations fail, drawing boundaries around what must not disagree, and refusing to start when a required choice has not been stated. Scaling appears far less often than the phrase "system design" suggests, and this document says so rather than padding.
Why This Exists
The expensive mistakes were rarely in a component. They were in the relationships between components, a boundary drawn in the wrong place, two writes sequenced by accident, a property assumed about something underneath. Those are decided before any code is written and are the most expensive things to revisit afterwards. The second reason is narrower. Several designs in this body of work were internally consistent, carefully reasoned, reviewed, and simply wrong about how a dependency behaved. Design review does not catch that class. Structure and explicit sequencing do.
Start with the decisions everything else is downstream of
Ordering is a design artifact
Branch on capability, never on identity
Separate by lifecycle, not by category
Draw the boundary around what must not disagree
Refuse to start rather than guess
What this standard does not cover
Related Principles· 3
Related Documents· 3
Related Case Studies
Referenced By· 12
Version History
- v0.1.0
Initial structure and metadata established.
- v0.2.0
Written from real experience. Covers upstream decisions, crash-safe ordering, capability-over-identity, lifecycle separation, the must-not-disagree boundary, and startup gates. It also states explicitly what it does not cover and why.