System Architect Skill
Design scalable, maintainable software systems.
When to Use
- Designing new system/feature
- Evaluating architectural trade-offs
- API/database/caching decisions
- Commands:
/architect, /design, /system-design
Capabilities
1. System Design
- Microservices vs monolith
- API design (REST, GraphQL, gRPC)
- DB selection & schema design
- Caching & message queues
- Event-driven systems
2. Scalability
- Horizontal/vertical scaling
- Load balancing & sharding
- CDN & auto-scaling
3. Reliability
- HA patterns & DR planning
- Circuit breaker & retry
- Graceful degradation
4. Security
- Auth systems (OAuth, JWT, SSO)
- Authorization (RBAC, ABAC)
- API security & encryption
Architecture Decision Process
Step 1: Requirements
1. Functional: Core features, workflows, integrations
2. Non-Functional: Performance, scalability, availability, security, budget
3. Constraints: Tech stack, team expertise, timeline, existing systems
Step 2: Pattern Selection
Reference patterns.json for patterns, tech recommendations, trade-offs.
Step 3: Design Doc Template
# Architecture Design Document
## 1. Overview
[High-level description]
## 2. Goals & Non-Goals
## 3. Architecture
### System Diagram
### Components
| Component | Responsibility | Technology |
|-----------|---------------|------------|
### Data Flow
## 4. Technical Decisions
### Decision 1: [Title]
- Context | Options | Decision | Rationale
## 5. API Design
## 6. Data Model
## 7. Security
## 8. Scalability
## 9. Monitoring & Observability
## 10. Risks & Mitigations
Pattern Reference
Communication
| Pattern |
Use When |
Trade-offs |
| Sync REST |
Simple CRUD |
Tight coupling |
| Async Queue |
Decoupling |
Complexity |
| Event Sourcing |
Audit trail |
Storage |
| CQRS |
Read/write opt |
Eventual consistency |
| GraphQL |
Flexible queries |
Caching |
| gRPC |
High perf |
Browser support |
Data
| Pattern |
Use When |
Trade-offs |
| SQL |
ACID, complex queries |
Scaling |
| NoSQL |
Flexibility, scale |
Consistency |
| Cache-aside |
Read-heavy |
Invalidation |
Resilience
| Pattern |
Purpose |
| Circuit Breaker |
Prevent cascade failures |
| Retry w/ Backoff |
Handle transient failures |
| Bulkhead |
Isolate failures |
| Timeout |
Prevent hanging |
| Fallback |
Graceful degradation |
Project Structures
Reference structures.json for:
- Python: FastAPI, Django
- TypeScript: Next.js, React, Express
- Java: Spring Boot
- Go: Standard Layout
Tech Stack Recommendations
Web Apps
Frontend: React/Next.js, Vue/Nuxt, Angular
Backend: Node.js, Go, Python (FastAPI), Rust
DB: PostgreSQL, MongoDB
Cache: Redis | Queue: RabbitMQ, SQS, Kafka
Search: Elasticsearch, Meilisearch
Real-time
WebSocket: Socket.io, ws
Pub/Sub: Redis, Kafka
Data-Intensive
Processing: Spark, Flink
Storage: S3, GCS
Warehouse: Snowflake, BigQuery
Pipeline: Airflow, Dagster
Diagramming
ASCII Component
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Client │────▶│ API Gateway │────▶│ Services │
└─────────────┘ └─────────────┘ └─────────────┘
│ │
▼ ▼
┌─────────────┐ ┌─────────────┐
│ Auth │ │ Database │
└─────────────┘ └─────────────┘
Mermaid Sequence
sequenceDiagram
Client->>API: Request
API->>Auth: Validate Token
Auth-->>API: Valid
API->>Service: Process
Service->>DB: Query
DB-->>Service: Data
Service-->>API: Response
API-->>Client: Response
Evaluation Criteria
| Criterion |
Weight |
Description |
| Scalability |
High |
Can it handle growth? |
| Maintainability |
High |
Easy to modify/debug? |
| Performance |
Med-High |
Meets latency/throughput? |
| Cost |
Medium |
Infra + dev cost |
| Security |
High |
Meets requirements? |
| Complexity |
Medium |
Team can build/operate? |
Output Templates
Quick Decision
**Question**: [What needs deciding]
**Recommendation**: [Approach]
**Rationale**: [Why]
**Trade-offs**: [Accepting]
**Alternatives**: [Other options]
Integration
- code-reviewer: Validate impl matches design
- postgres-mcp: DB schema design
- jira-bridge: Create impl tickets