system-design

System Design (orchestrator)

Drive an open-ended design problem from a vague prompt to a justified, stress-tested architecture — by reasoning, not by recalling a diagram. This skill owns the method and the routing; the actual component recipes live in focused building-block skills it pulls in as needed.

The single most important idea, from which everything here follows:

Do not memorize architectures; learn the forces that shape them. There is no single correct solution — success depends on the assumptions you make explicit.

A design that works for 1,000 users may fail at 1,000,000. Treat every architecture as a hypothesis that holds until a constraint changes, and be ready to redraw it calmly when one does.

The reasoning loop

Work this loop out loud. It is a loop, not a checklist — late steps routinely send you back to early ones, and that is the point.

1. Clarify requirements — turn the vague prompt into functional requirements, non-functional constraints, and an explicit out of scope. Scope to a few core features; say so. → skill requirements-scoping
2. Estimate scale — back-of-the-envelope QPS, storage, bandwidth, read/write ratio. Numbers decide the design; "high traffic" does not. → skill back-of-the-envelope
3. Propose a high-level design — sketch the boxes and arrows (clients, LB, services, stores, caches, queues, CDN) and the user-facing API. Get buy-in before going deep. → skill api-design, plus the building blocks below.
4. Evaluate trade-offs — for every major choice, state what it solves, what it worsens, and what would make you change it. Never name a tool without this. → reference tradeoff-framework.md
5. Stress-test failure modes — find single points of failure, decide the degradation story, plan recovery. Assume every component breaks. → skill resilience-failure
6. Iterate / deep-dive — pick the most interesting or fragile component and go deep; let new constraints ("what if writes 10×?", "lose a region?") drive a redesign of the affected part.