│ ├─ Pay-per-use model → Serverless (AWS Lambda, Cloudflare Workers)
│ └─ Batch processing → Serverless + queues
│
└─ High consistency requirements?
├─ Strong ACID guarantees → Monolith or Modular Monolith
└─ Distributed data → CQRS + Event Sourcing
Decision Factors:
Team size threshold
<10 developers → modular monolith typically outperforms microservices (operational overhead)
Team structure (Conway's Law) — architecture mirrors org structure
Deployment independence needs
Consistency vs availability tradeoffs (CAP theorem)
Operational maturity (monitoring, orchestration)
See
references/modern-patterns.md
for detailed pattern descriptions.
Output Guidelines
The references in this skill are background knowledge for you — absorb the patterns and present them as your own expertise. Do not cite internal reference file names (e.g., "from data-architecture-patterns.md") in user-facing output. Users don't know these files exist.
Every architecture recommendation should include:
Concrete technology picks
Name specific technologies (e.g., "Temporal.io for workflow orchestration", "Socket.io with Redis adapter") rather than staying abstract. The user needs to make build decisions, not just understand patterns.
What NOT to build
Explicitly call out what to defer or avoid. Premature scope is the #1 architecture mistake — help the user avoid it.
Team and process alignment
How does this architecture map to team structure? What ownership model does it imply? Include CODEOWNERS, deployment ownership, and on-call boundaries where relevant.
Success metrics
How will the team know the architecture is working? Include measurable indicators (deploy frequency, lead time, error rates, MTTR).
Focused length
Aim for depth on the 3–5 decisions that matter most rather than exhaustive coverage of every concern. A recommendation that's too long to read is a recommendation that won't be followed.
Workflow (System-Level)
Use this workflow when a user asks for architecture recommendations, decomposition, or major platform decisions.
Clarify: problem statement, non-goals, constraints, and success metrics
Capture quality attributes: availability, latency, throughput, durability, consistency, security, compliance, cost
Propose 2–3 candidate architectures and compare tradeoffs
Define boundaries: bounded contexts, ownership, APIs/events, integration contracts
Decide data strategy: storage, consistency model, schema evolution, migrations
Design for operations: SLOs, failure modes, observability, deployment, DR, incident playbooks
Call out scope limits: what NOT to build yet, what to defer, what to buy vs build
Document decisions: write ADRs for key tradeoffs and irreversible choices
Preferred deliverables (pick what fits the request):
Architecture blueprint:
assets/planning/architecture-blueprint.md
Decision record:
assets/planning/adr-template.md
Pattern deep dives:
references/modern-patterns.md
,
references/scalability-reliability-guide.md
2026 Considerations
Load only when the question explicitly involves current trends, vendor-specific constraints, or "what's the latest thinking on X?"
references/architecture-trends-2026.md
— Platform engineering, data mesh, composable architecture, AI-native systems
data/sources.json
— 60 curated resources organized by category:
platform_engineering_2026
— IDP trends, AI-platform convergence, Backstage
optional_ai_architecture
— RAG patterns, multi-agent design, MCP/A2A protocols
modern_architecture_2025
— Data mesh, composable architecture, continuous architecture
If live web access is available, consult 2–3 authoritative sources from
data/sources.json
and fold findings into the recommendation. If not, answer with durable patterns and explicitly state assumptions that could change (vendor limits, pricing, managed-service capabilities).
Navigation
Core References
Read
at most 2–3 references
per question — pick the ones most relevant to the specific ask. Do not read all of them.
Reference
Contents
When to Read
modern-patterns.md
10 architecture patterns with decision trees
Choosing or comparing patterns
scalability-reliability-guide.md
CAP theorem, DB scaling, caching, circuit breakers, SRE
Scaling or reliability questions
data-architecture-patterns.md
CQRS variants, event sourcing, data mesh, sagas, consistency
Data flow across services
migration-modernization-guide.md
Strangler fig, DB decomposition, feature flags, risk assessment
Refactoring a monolith
api-gateway-service-mesh.md
Gateway patterns, service mesh, mTLS, observability
Inter-service communication
architecture-trends-2026.md
Platform engineering, data mesh, AI-native systems
Current trends only
operational-playbook.md
Architecture questions framework, decomposition heuristics
Design discussion framing
Templates
Planning & Documentation
(
assets/planning/
):
architecture-blueprint.md
— Service blueprint (dependencies, SLAs, data flows, resilience, security, observability)
adr-template.md
— Architecture Decision Record for tradeoff analysis
Architecture Patterns
(
assets/patterns/
):
microservices-template.md
— Microservices design (API contracts, resilience, deployment, testing)
event-driven-template.md
— Event-driven architecture (event schemas, saga patterns, event sourcing)
Operations
(
assets/operations/
):
scalability-checklist.md
— Scalability checklist (DB scaling, caching, load testing, auto-scaling, DR)