Architecture Design
Overview
This skill enables you to design comprehensive software solution architectures including system components, technology stacks, integration patterns, scalability strategies, and deployment models.
Core Capabilities
When activated, this skill provides:
Requirements Analysis & Architecture Planning
Analyze functional and non-functional requirements
Identify architectural drivers (scalability, security, performance)
Define system boundaries and constraints
Establish architecture goals and success criteria
System Architecture Design
Design layered/tiered architectures
Create microservices and domain-driven designs
Design event-driven and message-based systems
Plan serverless and cloud-native architectures
Design monolithic, modular monolithic, or distributed systems
Technology Stack Selection
Evaluate and justify programming languages and frameworks
Select databases with rationale (SQL, NoSQL, time-series, graph)
Choose middleware and integration platforms (message queues, API gateways)
Select infrastructure and cloud platforms (assess vendor lock-in)
Recommend CI/CD and DevOps tools
Document technology decisions in ADRs with alternatives considered
Assess team skills and training needs for new technologies
Architecture Patterns & Best Practices
Apply design patterns (MVC, MVVM, Clean Architecture, Hexagonal)
Implement integration patterns (REST, GraphQL, gRPC, message queues)
Design for scalability (horizontal/vertical, caching, CDN)
Implement security patterns (OAuth, JWT, zero-trust)
Apply resilience patterns (circuit breakers, retries, bulkheads)
Documentation & Deliverables
Create C4 model diagrams in Mermaid format (Context, Container, Component, Code)
Generate Mermaid diagrams (class, sequence, deployment)
Produce architecture decision records (ADRs)
Write technical specifications and API contracts
Create implementation roadmaps and migration plans
Architecture Design Workflow
Follow this systematic process:
Step 1: Discovery & Requirements
Gather Requirements
Functional requirements (features, use cases)
Non-functional requirements (performance, scalability, security)
Business constraints (budget, timeline, compliance)
Technical constraints (existing systems, team skills)
Analyze Architecture Drivers
Performance: latency, throughput targets
Scalability: user growth, data volume projections
Availability: uptime SLA, disaster recovery needs
Security: authentication, authorization, compliance requirements
Maintainability: testability, modularity goals
Define System Context
Identify stakeholders and their needs
Map external systems and dependencies
Define system boundaries
Identify integration points
Step 2: Architecture Design
Choose Architecture Style
Select based on requirements and constraints:
Monolithic
Use for: Simple applications, MVPs, small teams, tight deadlines
Benefits: Simple deployment, strong consistency, no network overhead
Trade-offs: Scaling limitations, technology lock-in
Modular Monolithic
Use for: Medium complexity, clear domain boundaries
Benefits: Better organization, some isolation, shared infrastructure
Trade-offs: Still single deployment, limited independent scaling
Microservices
Use for: Large scale, multiple teams, different tech stacks
Benefits: Independent scaling/deployment, technology flexibility
Trade-offs: Distributed complexity, network overhead, eventual consistency
Serverless
Use for: Event-driven, variable load, rapid development
Benefits: Auto-scaling, pay-per-use, no infrastructure management
Trade-offs: Cold starts, vendor lock-in, debugging complexity
Event-Driven
Use for: Real-time processing, loose coupling, high throughput
Benefits: Scalability, flexibility, asynchronous processing
Trade-offs: Complexity, eventual consistency, debugging challenges
Design System Components
Define key layers and components:
┌─────────────────────────────────┐
│ Presentation Layer │ UI, Controllers, APIs
├─────────────────────────────────┤
│ Application Layer │ Use Cases, Orchestration
├─────────────────────────────────┤
│ Domain Layer │ Business Logic, Entities
├─────────────────────────────────┤
│ Data Layer │ Databases, Caches
├─────────────────────────────────┤
│ Infrastructure Layer │ External APIs, Services
└─────────────────────────────────┘
Define Data Architecture
Design data models and schemas
Choose database types (relational, document, graph, time-series)
Plan data partitioning and sharding strategies
Design caching layers (Redis, Memcached)
Define data flows and ETL processes
Design Integration Points
API design (REST, GraphQL, gRPC)
Message queues (Kafka, RabbitMQ, SQS)
Event streaming architectures
Authentication and authorization flows
Rate limiting and throttling strategies
Step 3: Document Architecture
Create Architecture Diagrams
Use C4 model in Mermaid format for comprehensive documentation:
Context : System in environment with users and external systems (use Mermaid C4Context)
Container : High-level technology choices and communication (use Mermaid C4Container)
Component : Internal structure of containers (use Mermaid C4Component)
Code : Class diagrams for complex components (use Mermaid classDiagram)
All diagrams should use Mermaid syntax for easy versioning and rendering in markdown.
Write Architecture Decision Records (ADRs)
Document all significant decisions using structured ADRs:
# ADR-001: [Decision Title]
## Status
Proposed | Accepted | Deprecated | Superseded
## Context
[Problem and constraints requiring decision]
## Decision
[Chosen solution and approach]
## Consequences
[Benefits and trade-offs]
Full ADR Template : See adr-template.md for complete structure with examples
Produce Technical Specifications
System overview and objectives
Component descriptions and responsibilities
API contracts and interfaces
Data models and schemas
Security and compliance measures
Deployment and operations guidelines
Step 4: Validate & Review
Quality Attributes Assessment
Performance: Response time, throughput
Scalability: Horizontal/vertical scaling capabilities
Availability: Fault tolerance, disaster recovery
Security: Authentication, authorization, encryption
Maintainability: Code organization, testability
Cost: Infrastructure and operational expenses
Design Validation Checklist
Ensure architecture is review-ready:
All functional and non-functional requirements addressed
Architecture style justified with trade-offs documented
Scalability strategy defined (horizontal/vertical, capacity planning)
Security measures implemented (authentication, authorization, encryption)
Data architecture validated (storage, consistency, replication)
Integration patterns specified (sync/async, APIs, events)
Monitoring and observability planned (metrics, logs, traces, alerts)
Disaster recovery and backup strategy documented (RPO/RTO)
Cost estimates provided (infrastructure, operations, scaling)
Architecture Decision Records (ADRs) created for major decisions
Reference Files
Load reference files based on specific needs:
Architecture Design Process : See architecture-design-process.md when:
Need detailed step-by-step guidance for complex architectures
Working through each phase systematically
Require comprehensive checklists and considerations
Architecture Patterns : See architecture-patterns.md when:
Need detailed pattern descriptions with benefits and trade-offs
Comparing multiple architecture styles
Looking for specific pattern implementations and examples
Technology Stack Guide : See technology-stack-guide.md when:
Evaluating specific technologies or frameworks
Need recommendations for databases, languages, or cloud platforms
Comparing technology options for specific requirements
Best Practices : See best-practices.md when:
Need design principles and guidelines
Looking for API design standards
Require security or operational best practices
Design Considerations : See design-considerations.md when:
Evaluating quality attributes (performance, scalability, security)
Need guidance on specific architectural concerns
Planning for observability, resilience, or cost optimization
Common Anti-Patterns : See common-anti-patterns-to-avoid.md when:
Reviewing existing architectures for issues
Validating design decisions
Need examples of what NOT to do
Migration Patterns : See migration-patterns.md when:
Modernizing legacy applications
Planning migration strategies
Need patterns for phased migrations or strangler fig approaches
Examples : See examples.md when:
Need complete architecture examples for common scenarios
Looking for real-world reference implementations
Want to see how patterns are applied in practice
Resources and References : See resources-and-references.md when:
Need external documentation links
Looking for additional learning resources
Require specifications or standards references
Output Format
Produce clear, comprehensive architecture documentation:
Architecture Overview
System purpose and scope
Key architecture decisions and rationale
High-level component diagram
Detailed Design
Component descriptions and responsibilities
Data models and schemas
API specifications
Integration patterns
Diagrams (All in Mermaid format)
C4 Context diagram (Mermaid C4Context)
C4 Container diagram (Mermaid C4Container)
Sequence diagrams for key flows (Mermaid sequenceDiagram)
Deployment diagram (Mermaid flowchart or C4Deployment)
Implementation Roadmap
Phase breakdown with milestones
Dependencies and sequencing
Resource requirements
Risk mitigation strategies
Architecture Decision Records
Document all significant decisions
Include context, alternatives, and trade-offs
Converted and distributed by TomeVault — claim your Tome and manage your conversions.
1 --- 2 name: architecture-design-5 3 description: Designs comprehensive software solution architectures including system components, technology stacks, integration patterns, scalability strategies, and deployment models. Produces architecture diagrams, technical specifications, and implementation roadmaps. Use when planning new software systems, modernizing legacy applications, designing microservices, evaluating technology choices, creating architecture documentation, or when users mention system design, architecture patterns, scalability planning, or technical architecture decisions. Use when this capability is needed. 4 --- 5 6 # Architecture Design 7 8 ## Overview 9 10 This skill enables you to design comprehensive software solution architectures including system components, technology stacks, integration patterns, scalability strategies, and deployment models. 11 12 ## Core Capabilities 13 14 When activated, this skill provides: 15 16 1. **Requirements Analysis & Architecture Planning** 17 - Analyze functional and non-functional requirements 18 - Identify architectural drivers (scalability, security, performance) 19 - Define system boundaries and constraints 20 - Establish architecture goals and success criteria 21 22 2. **System Architecture Design** 23 - Design layered/tiered architectures 24 - Create microservices and domain-driven designs 25 - Design event-driven and message-based systems 26 - Plan serverless and cloud-native architectures 27 - Design monolithic, modular monolithic, or distributed systems 28 29 3. **Technology Stack Selection** 30 - Evaluate and justify programming languages and frameworks 31 - Select databases with rationale (SQL, NoSQL, time-series, graph) 32 - Choose middleware and integration platforms (message queues, API gateways) 33 - Select infrastructure and cloud platforms (assess vendor lock-in) 34 - Recommend CI/CD and DevOps tools 35 - Document technology decisions in ADRs with alternatives considered 36 - Assess team skills and training needs for new technologies 37 38 4. **Architecture Patterns & Best Practices** 39 - Apply design patterns (MVC, MVVM, Clean Architecture, Hexagonal) 40 - Implement integration patterns (REST, GraphQL, gRPC, message queues) 41 - Design for scalability (horizontal/vertical, caching, CDN) 42 - Implement security patterns (OAuth, JWT, zero-trust) 43 - Apply resilience patterns (circuit breakers, retries, bulkheads) 44 45 5. **Documentation & Deliverables** 46 - Create C4 model diagrams in Mermaid format (Context, Container, Component, Code) 47 - Generate Mermaid diagrams (class, sequence, deployment) 48 - Produce architecture decision records (ADRs) 49 - Write technical specifications and API contracts 50 - Create implementation roadmaps and migration plans 51 52 ## Architecture Design Workflow 53 54 Follow this systematic process: 55 56 ## Step 1: Discovery & Requirements 57 58 1. **Gather Requirements** 59 - Functional requirements (features, use cases) 60 - Non-functional requirements (performance, scalability, security) 61 - Business constraints (budget, timeline, compliance) 62 - Technical constraints (existing systems, team skills) 63 64 2. **Analyze Architecture Drivers** 65 - Performance: latency, throughput targets 66 - Scalability: user growth, data volume projections 67 - Availability: uptime SLA, disaster recovery needs 68 - Security: authentication, authorization, compliance requirements 69 - Maintainability: testability, modularity goals 70 71 3. **Define System Context** 72 - Identify stakeholders and their needs 73 - Map external systems and dependencies 74 - Define system boundaries 75 - Identify integration points 76 77 ### Step 2: Architecture Design 78 79 1. **Choose Architecture Style** 80 81 Select based on requirements and constraints: 82 83 **Monolithic** 84 85 - Use for: Simple applications, MVPs, small teams, tight deadlines 86 - Benefits: Simple deployment, strong consistency, no network overhead 87 - Trade-offs: Scaling limitations, technology lock-in 88 89 **Modular Monolithic** 90 91 - Use for: Medium complexity, clear domain boundaries 92 - Benefits: Better organization, some isolation, shared infrastructure 93 - Trade-offs: Still single deployment, limited independent scaling 94 95 **Microservices** 96 97 - Use for: Large scale, multiple teams, different tech stacks 98 - Benefits: Independent scaling/deployment, technology flexibility 99 - Trade-offs: Distributed complexity, network overhead, eventual consistency 100 101 **Serverless** 102 103 - Use for: Event-driven, variable load, rapid development 104 - Benefits: Auto-scaling, pay-per-use, no infrastructure management 105 - Trade-offs: Cold starts, vendor lock-in, debugging complexity 106 107 **Event-Driven** 108 109 - Use for: Real-time processing, loose coupling, high throughput 110 - Benefits: Scalability, flexibility, asynchronous processing 111 - Trade-offs: Complexity, eventual consistency, debugging challenges 112 113 1. **Design System Components** 114 115 Define key layers and components: 116 117 ``` 118 ┌─────────────────────────────────┐ 119 │ Presentation Layer │ UI, Controllers, APIs 120 ├─────────────────────────────────┤ 121 │ Application Layer │ Use Cases, Orchestration 122 ├─────────────────────────────────┤ 123 │ Domain Layer │ Business Logic, Entities 124 ├─────────────────────────────────┤ 125 │ Data Layer │ Databases, Caches 126 ├─────────────────────────────────┤ 127 │ Infrastructure Layer │ External APIs, Services 128 └─────────────────────────────────┘ 129 ``` 130 131 1. **Define Data Architecture** 132 - Design data models and schemas 133 - Choose database types (relational, document, graph, time-series) 134 - Plan data partitioning and sharding strategies 135 - Design caching layers (Redis, Memcached) 136 - Define data flows and ETL processes 137 138 2. **Design Integration Points** 139 - API design (REST, GraphQL, gRPC) 140 - Message queues (Kafka, RabbitMQ, SQS) 141 - Event streaming architectures 142 - Authentication and authorization flows 143 - Rate limiting and throttling strategies 144 145 ### Step 3: Document Architecture 146 147 1. **Create Architecture Diagrams** 148 149 Use C4 model in Mermaid format for comprehensive documentation: 150 151 - **Context**: System in environment with users and external systems (use Mermaid C4Context) 152 - **Container**: High-level technology choices and communication (use Mermaid C4Container) 153 - **Component**: Internal structure of containers (use Mermaid C4Component) 154 - **Code**: Class diagrams for complex components (use Mermaid classDiagram) 155 156 All diagrams should use Mermaid syntax for easy versioning and rendering in markdown. 157 158 1. **Write Architecture Decision Records (ADRs)** 159 160 Document all significant decisions using structured ADRs: 161 162 ```markdown 163 # ADR-001: [Decision Title] 164 165 ## Status 166 Proposed | Accepted | Deprecated | Superseded 167 168 ## Context 169 [Problem and constraints requiring decision] 170 171 ## Decision 172 [Chosen solution and approach] 173 174 ## Consequences 175 [Benefits and trade-offs] 176 ``` 177 178 **Full ADR Template**: See [adr-template.md](references/adr-template.md) for complete structure with examples 179 180 1. **Produce Technical Specifications** 181 - System overview and objectives 182 - Component descriptions and responsibilities 183 - API contracts and interfaces 184 - Data models and schemas 185 - Security and compliance measures 186 - Deployment and operations guidelines 187 188 ### Step 4: Validate & Review 189 190 1. **Quality Attributes Assessment** 191 - Performance: Response time, throughput 192 - Scalability: Horizontal/vertical scaling capabilities 193 - Availability: Fault tolerance, disaster recovery 194 - Security: Authentication, authorization, encryption 195 - Maintainability: Code organization, testability 196 - Cost: Infrastructure and operational expenses 197 198 2. **Design Validation Checklist** 199 200 Ensure architecture is review-ready: 201 202 - [ ] All functional and non-functional requirements addressed 203 - [ ] Architecture style justified with trade-offs documented 204 - [ ] Scalability strategy defined (horizontal/vertical, capacity planning) 205 - [ ] Security measures implemented (authentication, authorization, encryption) 206 - [ ] Data architecture validated (storage, consistency, replication) 207 - [ ] Integration patterns specified (sync/async, APIs, events) 208 - [ ] Monitoring and observability planned (metrics, logs, traces, alerts) 209 - [ ] Disaster recovery and backup strategy documented (RPO/RTO) 210 - [ ] Cost estimates provided (infrastructure, operations, scaling) 211 - [ ] Architecture Decision Records (ADRs) created for major decisions 212 213 ## Reference Files 214 215 Load reference files based on specific needs: 216 217 - **Architecture Design Process**: See [architecture-design-process.md](references/architecture-design-process.md) when: 218 - Need detailed step-by-step guidance for complex architectures 219 - Working through each phase systematically 220 - Require comprehensive checklists and considerations 221 222 - **Architecture Patterns**: See [architecture-patterns.md](references/architecture-patterns.md) when: 223 - Need detailed pattern descriptions with benefits and trade-offs 224 - Comparing multiple architecture styles 225 - Looking for specific pattern implementations and examples 226 227 - **Technology Stack Guide**: See [technology-stack-guide.md](references/technology-stack-guide.md) when: 228 - Evaluating specific technologies or frameworks 229 - Need recommendations for databases, languages, or cloud platforms 230 - Comparing technology options for specific requirements 231 232 - **Best Practices**: See [best-practices.md](references/best-practices.md) when: 233 - Need design principles and guidelines 234 - Looking for API design standards 235 - Require security or operational best practices 236 237 - **Design Considerations**: See [design-considerations.md](references/design-considerations.md) when: 238 - Evaluating quality attributes (performance, scalability, security) 239 - Need guidance on specific architectural concerns 240 - Planning for observability, resilience, or cost optimization 241 242 - **Common Anti-Patterns**: See [common-anti-patterns-to-avoid.md](references/common-anti-patterns-to-avoid.md) when: 243 - Reviewing existing architectures for issues 244 - Validating design decisions 245 - Need examples of what NOT to do 246 247 - **Migration Patterns**: See [migration-patterns.md](references/migration-patterns.md) when: 248 - Modernizing legacy applications 249 - Planning migration strategies 250 - Need patterns for phased migrations or strangler fig approaches 251 252 - **Examples**: See [examples.md](references/examples.md) when: 253 - Need complete architecture examples for common scenarios 254 - Looking for real-world reference implementations 255 - Want to see how patterns are applied in practice 256 257 - **Resources and References**: See [resources-and-references.md](references/resources-and-references.md) when: 258 - Need external documentation links 259 - Looking for additional learning resources 260 - Require specifications or standards references 261 262 ## Output Format 263 264 Produce clear, comprehensive architecture documentation: 265 266 1. **Architecture Overview** 267 - System purpose and scope 268 - Key architecture decisions and rationale 269 - High-level component diagram 270 271 2. **Detailed Design** 272 - Component descriptions and responsibilities 273 - Data models and schemas 274 - API specifications 275 - Integration patterns 276 277 3. **Diagrams (All in Mermaid format)** 278 - C4 Context diagram (Mermaid C4Context) 279 - C4 Container diagram (Mermaid C4Container) 280 - Sequence diagrams for key flows (Mermaid sequenceDiagram) 281 - Deployment diagram (Mermaid flowchart or C4Deployment) 282 283 4. **Implementation Roadmap** 284 - Phase breakdown with milestones 285 - Dependencies and sequencing 286 - Resource requirements 287 - Risk mitigation strategies 288 289 5. **Architecture Decision Records** 290 - Document all significant decisions 291 - Include context, alternatives, and trade-offs 292 293 --- 294 > Converted and distributed by [TomeVault](https://tomevault.io/claim/dauquangthanh) — claim your Tome and manage your conversions. 295 <!-- tomevault:4.0:skill_md:2026-04-11 -->