Arch Agent — Senior Cloud Architect

Your expert agent for modern cloud architecture design, covering microservices, event-driven systems, serverless, and cloud-native patterns with deep focus on non-functional requirements.

When to Use This Agent

Choose Arch Agent when:

• Designing system architecture for new applications or major refactors
• Evaluating architecture patterns (microservices vs monolith, event-driven vs request-response)
• Creating architecture decision records (ADRs) for technology choices
• Reviewing existing architectures for scalability, reliability, and security gaps
• Designing data pipelines, event processing, or integration architectures

Consider alternatives when:

• You need infrastructure provisioning (Terraform, CloudFormation) — use an IaC agent
• You need specific cloud provider services — use a cloud-provider-specific agent
• You need code-level design patterns — use a software design pattern agent

Quick Start

Copy
# .claude/agents/arch-agent.yml
name: Arch Agent
model: claude-sonnet
tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
description: Senior cloud architect agent for system design, architecture patterns, and non-functional requirements

Example invocation:

claude "Design an event-driven architecture for an e-commerce platform that handles 50K orders/day with real-time inventory updates, payment processing, and notification delivery"

Core Concepts

Architecture Decision Framework

Factor	Question	Trade-offs
Scalability	How does the system handle 10x load?	Horizontal vs vertical, cost vs headroom
Reliability	What's the availability target?	Redundancy cost vs downtime impact
Consistency	Strong or eventual consistency?	Latency vs data accuracy
Security	What's the threat model?	Usability vs protection
Maintainability	Can teams work independently?	Service boundaries vs complexity
Cost	What's the budget constraint?	Performance vs operational cost

Architecture Patterns

Monolith → Modular Monolith → Microservices
    ↓              ↓                ↓
  Simple       Balanced         Complex
  Coupled      Bounded          Independent
  Fast dev     Moderate         Team scaling
  Low ops      Medium ops       High ops

Event-Driven Patterns:
  Event Notification → Event-Carried State Transfer → Event Sourcing → CQRS
      Simple               Decoupled                  Full audit       Read/write split

Configuration

Parameter	Description	Default
architecture_style	Primary pattern (monolith, microservices, serverless)	context-dependent
cloud_provider	Target cloud (aws, azure, gcp, multi-cloud)	aws
scale_target	Expected traffic/load profile	provided per project
availability_target	Required uptime (99.9%, 99.99%)	99.9%
output_format	Deliverable format (adr, diagram, rfc, design-doc)	design-doc

Best Practices

1. Start with business requirements, not technology choices. Understand traffic patterns, SLA requirements, team structure, and budget before selecting architecture patterns. A microservices architecture for a 3-developer team building an internal tool is over-engineering; a monolith for a 200-person engineering org may be under-engineering.

2. Document architectural decisions as ADRs. Record the context, decision, alternatives considered, and consequences for every significant choice. Future developers (and future you) need to understand why decisions were made, not just what they were.

3. Design for failure at every layer. Assume networks are unreliable, services crash, databases fail, and third-party APIs go down. Implement circuit breakers, retries with backoff, graceful degradation, and fallback responses. The question isn't "will it fail?" but "how will it behave when it fails?"

4. Use the strangler fig pattern for incremental migration. Don't rewrite entire systems. Route traffic through a facade that gradually directs requests to new services while the legacy system shrinks. This reduces risk and delivers value incrementally.

5. Right-size your service boundaries. Too many small services create distributed monolith problems (chatty inter-service calls, deployment complexity). Too few large services recreate monolith problems. Align boundaries with business domains and team ownership — one team should own one to three services.

Common Issues

Distributed transactions across microservices cause data inconsistency. Two-phase commit doesn't work reliably across services. Use the saga pattern — a sequence of local transactions with compensating actions for rollback. Implement an orchestrator or choreography-based saga depending on your complexity tolerance.

Service-to-service communication creates cascading failures. When service A calls B calls C, a failure in C brings down A and B. Implement circuit breakers (Resilience4j, Polly) that fail fast, return cached responses or defaults during outages, and use asynchronous messaging for non-critical paths.

Architecture diagrams become stale within weeks. Static diagrams rot because updating them requires manual effort. Generate diagrams from code (Structurizr, C4 model DSL) or infrastructure definitions so they stay current automatically. Store diagram source files alongside the code they describe.