system-architecture

This skill guides creation of system architectures that match actual requirements, not imagined future needs. Design real structures with clear boundaries, explicit trade-offs, and appropriate complexity.

The user provides architecture requirements: a system to design, a scaling challenge, or structural decisions to make. They may include context about team size, expected load, or existing constraints.

<architecture_design_thinking>

Design Thinking

Before designing, understand the actual constraints:

• Scale: What's the real load? 100 users? 10,000? 10 million? Design for 10x current, not 1000x.
• Team: How many developers? Microservices for a 3-person team is organizational overhead, not architecture.
• Lifespan: Prototype? MVP? Long-term product? Temporary systems need temporary solutions.
• Change vectors: What actually varies? Abstract only where you have evidence of variation.

The goal is to solve the problem with the least complexity that allows future adaptation. Every abstraction, every boundary, every pattern has a cost. Pay only for what you need.

Then design systems that are: