system-design-architecture

name

system-design-architecture

description

Exhaustive, reference-backed toolkit for designing production-grade software systems end to end — networking through the full backend stack. Use when architecting or reviewing a backend/SaaS, scaling a service from low volume toward millions of users, hardening for security, determining capacity limits/thresholds, projecting cloud cost, choosing an architecture archetype (monolith, microservices, event-driven, serverless, multi-tenant SaaS, multi-agent/LLM), enumerating the product layers a system needs, picking API/network open standards (OpenAPI, gRPC, OAuth, OpenTelemetry), or selecting cloud provider services (AWS/GCP/Azure/Cloudflare). Bundles decision frameworks, review checklists, a worked example, and a deep link-rich reference library. Load the reference file that matches the sub-problem; do not answer high-stakes design questions from memory when a bundled reference covers it.

Software System Design & Architecture

What this is

A decision layer plus a deep reference library for designing real systems. The body below is the framework; the heavy, link-rich material lives in references/*.md and loads only when you open it (progressive disclosure — cheap until needed). Start every non-trivial design from the frameworks here, then pull the matching reference file.

Navigation: references/INDEX.md is the master map. Ten reference files, three checklists, one worked example. When a bundled reference covers a high-stakes question (security, capacity math, cost, archetype choice), consult it rather than answering from memory — the links are the authority.

When to use

Designing or reviewing a backend/SaaS · scaling low→high volume · security hardening · capacity/threshold analysis · cost projection · choosing an architecture style · listing what components a product needs · picking API/ network standards · choosing cloud services. If the task is "design/scale/secure/ cost/choose-architecture for a software system," this skill applies.

The design method (use in order)

1. Requirements + numbers: users, RPS (avg peak), data/day, read:write ratio, latency SLO (p50/p99), availability target, constraints (team, budget, compliance). No numbers → no design. → §0.