architecture-selection_skill
- Shell
168
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill rsmdt/the-startup --skill architecture-selection- SKILL.md27.4 KB
Overview
This skill provides practical guidance for selecting system architecture patterns (monolith, microservices, event-driven, serverless) and documenting choices with the C4 model. It helps match patterns to team size, domain complexity, scaling needs, and operational maturity. The skill also recommends scalability strategies and technology selection criteria to support implementation.
How this skill works
The skill evaluates requirements such as team size, domain complexity, SLAs, scaling profile, and operational capability to recommend fitting patterns and trade-offs. It maps recommendations to C4 documentation levels (System Context, Container, Component, Code) and suggests concrete scalability patterns (horizontal scaling, message buses, CQRS, caching). It also provides technology selection criteria and checklist items for deployment, monitoring, and testing.
When to use it
- Designing a new system or refactor strategy
- Choosing between monolith, microservices, event-driven, or serverless
- Planning scaling and high-availability strategies
- Preparing architecture documentation with C4 diagrams
- Evaluating tech choices against team skills and ops maturity
Best practices
- Start with requirements and constraints, not pattern preferences
- Use the smallest viable architecture that meets needs; avoid premature microservices
- Document at C4 levels: context, containers, components, and code specifics
- Define clear boundaries, communication contracts, and ownership for services
- Plan for observability, automated tests, and deployment workflows early
- Prefer incremental migration paths and measure before large-scale changes
Example use cases
- Small startup needs fast iteration: recommend monolith with modular structure and clear CI/CD
- Large product with multiple teams: propose microservices with API gateway and message bus for asynchronous flows
- Event-driven pipeline for complex workflows and auditability, using topics and idempotent consumers
- Serverless for unpredictable traffic or event-triggered tasks to reduce ops overhead and cost
- Create C4 diagrams to hand off architecture to engineers and stakeholders
FAQ
Compare team size, domain complexity, required independent scaling, and ops maturity. Choose monolith for small teams and simple domains; choose microservices when teams are large, boundaries are clear, and operational capability exists.
When is event-driven architecture a poor fit?
Avoid event-driven design when synchronous consistency is mandatory, team familiarity with distributed systems is low, or debugging and ordering guarantees would create unacceptable risk.
