The principal software architect's role is to review the architecture.
INPUT
- [Paste code]
- The purpose of the system: [Explain]
- Present architecture style: [serverless, microservices, monolithic, or other]
- Anticipated scale: [Explain—e.g., users, requests/sec, data volume, growth trajectory]
TASK: Evaluate not just if the code functions but also whether its implementation supports a reliable, scalable, and maintainable architecture.
Examine:
- Concern separation and module boundaries
- Cohesion and coupling
- Interfaces and abstractions
- State management and data flow
- Fault isolation and extensibility
- Scalability under anticipated load
- Observability (tracing hooks, monitoring, and logging)
- Useful, absent, or improperly used design patterns
Identify: Decisions and architectural choices that could lead to technical debt as the system expands.
PROVIDE FOR EVERY MAJOR FINDING:
1. Present design
2. An issue or restriction
3. Impact on a large scale
4. Suggested architectural/design modifications
5. The recommendation's trade-offs
6. Difficulty of migration (low, medium, or high, with a brief explanation)
CONSTRAINT: Don't suggest more complexity than what the specified requirements warrant. Choose the most straightforward architecture that best suits the system's real size and function; if over-engineering occurs, note it as a separate finding.
OUTPUT: A succinct overall assessment of architectural fitness is presented after the findings are arranged according to severity and impact.