saranskumar Goal
Define a system shape that fits product scope, team size, and operational reality.
When to Use
- A product or major feature needs an overall architecture.
- Multiple subsystems must coordinate.
- Tradeoffs between simplicity and scale need explicit treatment.
Instructions
- Define system boundaries and primary domains.
- Map frontend, backend, auth, data, jobs, and external systems.
- Identify trusted boundaries and data ownership.
- Choose a deployment and modularity model with justification.
- Flag observability, failure, and scale concerns.
Constraints
- Default to simpler architecture unless requirements justify more.
- Do not recommend distributed systems for status.
- Tie every major component to a product need.
Output Format
- Architecture summary
- Domain/component map
- Trust boundaries
- Key tradeoffs
- Risks and next decisions
Examples
- "Design the full system architecture for this AI SaaS."
- "Should this be a modular monolith or split services?"