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.

This section is about how to design: where to start, what each block costs, what the method looks like on a real task, and how to defend the result. The paired section Architectural Choice is "how to resolve specific decision points" within that process.

Articles in the section

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

The theory the method rests on

Storage internals and the nature of distributed failures live in their own sections — read them alongside the method or after it.

• Data foundations — storage engines, OLTP and OLAP, replication, sharding, derived data, streams.
• Distributed systems — partial failures, unreliable clocks, linearizability, consensus, correctness.

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.