architecture-designlisted

# Architecture Design A diagram of boxes and arrows is not an architecture. An architecture is a set of trade-off decisions that someone was forced to make explicitly, plus a description of how the system fails. This skill forces both. ## Step 1 — Requirements framing (get this explicit before designing anything) - **Functional**: what the system actually has to do. - **Non-functional, with numbers where possible**: latency budget, throughput, consistency requirement, availability target, cost ceiling, and — for edge/embedded components — power and thermal budget. Vague non-functional requirements ("fast," "scalable") are not requirements; push for numbers or explicit ranges. ## Step 2 — Force the trade-off decisions, don't hide them Every non-trivial system has to pick a side on things that can't be maximized simultaneously. Make each decision explicit and state what's being given up: - Consistency vs. availability under partition, and where in the system this boundary actually sits. - Synchronous vs. asynchronous boundaries between components, and what breaks if a downstream service is slow. - Where compute is placed — edge vs. cloud — and what happens when connectivity to the other side is lost. - Who owns which piece of state, and what the source of truth is when two components disagree. If the design avoids naming any of these, that's a sign the trade-offs weren't actually decided — just deferred to production. ## Step 3 — Component decomposition and data flow Pr