# Architecture Patterns

> 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: `majiayu000/architecture-patterns-5` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/architecture-patterns-5`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/architecture-patterns-5/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/architecture-patterns-5

---


# 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"