System design

Why it matters for UCP. Before you write a service's spec and code, the system has to be designed: numbers, storage, arrows, failures. This section is a practical design method; its outputs (the diagram, the decision points, the behavior) then live on in ADRs and UCP specs. Part of the training program.

The section is split into four articles: the method, the vocabulary of blocks, an end-to-end example, and formalizing the result. This is "how to design"; the paired section Architectural Choice is "how to resolve specific decision points" within that process.

Articles in the section

1. The method: step by step — nine steps from requirements to architecture and four principles that hold the process together.
2. Building blocks and their cost — cache, replication, sharding, queues, search, analytics: what each buys you, what it costs, and which number triggers it.
3. End-to-end example: a notification system — the whole method on a single task, from napkin sketch to a failure table.
4. Formalizing and defending: design doc, C4, review — how a design becomes a decision.

Related

• Architectural Choice — the decision points of steps 5–6: storage, sync/async, the web stack.
• The C4 Model — the diagram language for the schema.
• Distributed patterns — outbox, saga, idempotency in combinations of blocks.
• Use Case Pattern — where the behavior goes after the design review.