Architecture patterns
Skill AhmedHabiba/architor/.claude/skills/architecture-patterns
Structured, phase-gated architecture design powered by Claude Code. Enforces decision gates, challenges assumptions, and produces documented architecture decisions.
npx -y skills add AhmedHabiba/architor --skill architecture-patternsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 6 stars6 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Knowledge base for architecture patterns, trade-offs, and selection criteria. Activates when recommending or evaluating architecture patterns like microservices, monolith, serverless, event-driven, CQRS, or hybrid approaches.
SKILL.md
3.1 KB, as published. Nobody here has run it
Architecture Patterns Knowledge
Pattern Selection Framework
When recommending a pattern, evaluate against these criteria:
Team Fit
- Team size < 5 → Strongly favor monolith or modular monolith
- Team size 5-15 → Modular monolith or bounded microservices
- Team size 15+ → Microservices viable if org supports it
- No DevOps/Platform team → Avoid Kubernetes-heavy architectures
- Junior-heavy team → Favor simpler patterns with clear boundaries
Operational Reality
- 1 DevOps engineer → Cannot sustain >3 independently deployed services
- No dedicated DBA → Avoid polyglot persistence
- Limited monitoring experience → Start with monolith + good observability
- Budget constrained → Serverless for spiky loads, monolith for steady
Requirement Signals
- Independent scaling needs → Microservices or serverless
- Strong consistency requirements → Monolith or synchronous microservices
- Event-heavy domain → Event-driven architecture
- Read/write asymmetry → CQRS
- Rapid experimentation needed → Modular monolith (fastest to change)
- Regulatory isolation → Service per compliance boundary
Pattern Comparison Quick Reference
Monolith
- Best for: Small teams, rapid development, strong consistency needs
- Risks: Scaling bottleneck, deployment coupling, team scaling limits
- Migrate to: Modular monolith → microservices (progressive)
Modular Monolith
- Best for: Teams 3-10, need clear boundaries without operational overhead
- Risks: Module coupling creep, single deployment unit
- Migrate to: Extract modules to services as needed
Microservices
- Best for: Large teams, independent scaling, polyglot needs
- Risks: Distributed system complexity, data consistency, operational overhead
- Prerequisite: CI/CD maturity, monitoring, team autonomy
Event-Driven
- Best for: Async workflows, decoupled services, audit trails
- Risks: Eventual consistency complexity, debugging difficulty, event schema evolution
- Prerequisite: Team comfort with async patterns, good monitoring
Serverless-First
- Best for: Spiky workloads, cost optimization at low scale, rapid prototyping
- Risks: Cold starts, vendor lock-in, debugging difficulty, cost at scale
- Prerequisite: Cloud-native comfort, stateless design skills
CQRS
- Best for: Read-heavy systems, different read/write models, event sourcing
- Risks: Complexity, eventual consistency, increased codebase size
- Prerequisite: Strong domain modeling skills
Red Flags by Pattern
- Microservices with shared database → "You have a distributed monolith"
- Event sourcing without replay testing → "You'll lose data"
- Serverless with persistent connections → "Wrong pattern for this workload"
- CQRS for simple CRUD → "Over-engineered"
- Monolith with 50+ developers → "Deployment bottleneck incoming"