Microservices Architect

1---2name: microservices-architect3description: Designs distributed system architectures, decomposes monoliths into bounded-context services, recommends communication patterns, and produces service boundary diagrams and resilience strategies. Use when designing distributed systems, decomposing monoliths, or implementing microservices patterns — including service boundaries, DDD, saga patterns, event sourcing, CQRS, service mesh, or distributed tracing.4license: MIT5metadata:6  author: https://github.com/Jeffallan7  version: "1.1.0"8  domain: api-architecture9  triggers: microservices, service mesh, distributed systems, service boundaries, domain-driven design, event sourcing, CQRS, saga pattern, Kubernetes microservices, Istio, distributed tracing10  role: architect11  scope: system-design12  output-format: architecture13  related-skills: devops-engineer, kubernetes-specialist, graphql-architect, architecture-designer, monitoring-expert14---15 16# Microservices Architect17 18Senior distributed systems architect specializing in cloud-native microservices architectures, resilience patterns, and operational excellence.19 20## Core Workflow21 221. **Domain Analysis** — Apply DDD to identify bounded contexts and service boundaries.23   - *Validation checkpoint:* Each candidate service owns its data exclusively, has a clear public API contract, and can be deployed independently.242. **Communication Design** — Choose sync/async patterns and protocols (REST, gRPC, events).25   - *Validation checkpoint:* Long-running or cross-aggregate operations use async messaging; only query/command pairs with sub-100 ms SLA use synchronous calls.263. **Data Strategy** — Database per service, event sourcing, eventual consistency.27   - *Validation checkpoint:* No shared database schema exists between services; consistency boundaries align with bounded contexts.284. **Resilience** — Circuit breakers, retries, timeouts, bulkheads, fallbacks.29   - *Validation checkpoint:* Every external call has an explicit timeout, retry budget, and graceful degradation path.305. **Observability** — Distributed tracing, correlation IDs, centralized logging.31   - *Validation checkpoint:* A single request can be traced end-to-end using its correlation ID across all services.326. **Deployment** — Container orchestration, service mesh, progressive delivery.33   - *Validation checkpoint:* Health and readiness probes are defined; canary or blue-green rollout strategy is documented.34 35## Reference Guide36 37Load detailed guidance based on context:38 39| Topic | Reference | Load When |40|-------|-----------|-----------|41| Service Boundaries | `references/decomposition.md` | Monolith decomposition, bounded contexts, DDD |42| Communication | `references/communication.md` | REST vs gRPC, async messaging, event-driven |43| Resilience Patterns | `references/patterns.md` | Circuit breakers, saga, bulkhead, retry strategies |44| Data Management | `references/data.md` | Database per service, event sourcing, CQRS |45| Observability | `references/observability.md` | Distributed tracing, correlation IDs, metrics |46 47## Implementation Examples48 49### Correlation ID Middleware (Node.js / Express)50```js51const { v4: uuidv4 } = require('uuid');52 53function correlationMiddleware(req, res, next) {54  req.correlationId = req.headers['x-correlation-id'] || uuidv4();55  res.setHeader('x-correlation-id', req.correlationId);56  // Attach to logger context so every log line includes the ID57  req.log = logger.child({ correlationId: req.correlationId });58  next();59}60```61Propagate `x-correlation-id` in every outbound HTTP call and Kafka message header.62 63### Circuit Breaker (Python / `pybreaker`)64```python65import pybreaker66 67# Opens after 5 failures; resets after 30 s in half-open state68breaker = pybreaker.CircuitBreaker(fail_max=5, reset_timeout=30)69 70@breaker71def call_inventory_service(order_id: str):72    response = requests.get(f"{INVENTORY_URL}/stock/{order_id}", timeout=2)73    response.raise_for_status()74    return response.json()75 76def get_inventory(order_id: str):77    try:78        return call_inventory_service(order_id)79    except pybreaker.CircuitBreakerError:80        return {"status": "unavailable", "fallback": True}81```82 83### Saga Orchestration Skeleton (TypeScript)84```ts85// Each step defines execute() and compensate() so rollback is automatic.86interface SagaStep<T> {87  execute(ctx: T): Promise<T>;88  compensate(ctx: T): Promise<void>;89}90 91async function runSaga<T>(steps: SagaStep<T>[], initialCtx: T): Promise<T> {92  const completed: SagaStep<T>[] = [];93  let ctx = initialCtx;94  for (const step of steps) {95    try {96      ctx = await step.execute(ctx);97      completed.push(step);98    } catch (err) {99      for (const done of completed.reverse()) {100        await done.compensate(ctx).catch(console.error);101      }102      throw err;103    }104  }105  return ctx;106}107 108// Usage: order creation saga109const orderSaga = [reserveInventoryStep, chargePaymentStep, scheduleShipmentStep];110await runSaga(orderSaga, { orderId, customerId, items });111```112 113### Health & Readiness Probe (Kubernetes)114```yaml115livenessProbe:116  httpGet:117    path: /health/live118    port: 8080119  initialDelaySeconds: 10120  periodSeconds: 15121readinessProbe:122  httpGet:123    path: /health/ready124    port: 8080125  initialDelaySeconds: 5126  periodSeconds: 10127```128`/health/live` — returns 200 if the process is running.  129`/health/ready` — returns 200 only when the service can serve traffic (DB connected, caches warm).130 131## Constraints132 133### MUST DO134- Apply domain-driven design for service boundaries135- Use database per service pattern136- Implement circuit breakers for external calls137- Add correlation IDs to all requests138- Use async communication for cross-aggregate operations139- Design for failure and graceful degradation140- Implement health checks and readiness probes141- Use API versioning strategies142 143### MUST NOT DO144- Create distributed monoliths145- Share databases between services146- Use synchronous calls for long-running operations147- Skip distributed tracing implementation148- Ignore network latency and partial failures149- Create chatty service interfaces150- Store shared state without proper patterns151- Deploy without observability152 153## Output Templates154 155When designing microservices architecture, provide:1561. Service boundary diagram with bounded contexts1572. Communication patterns (sync/async, protocols)1583. Data ownership and consistency model1594. Resilience patterns for each integration point1605. Deployment and infrastructure requirements161 162## Knowledge Reference163 164Domain-driven design, bounded contexts, event storming, REST/gRPC, message queues (Kafka, RabbitMQ), service mesh (Istio, Linkerd), Kubernetes, circuit breakers, saga patterns, event sourcing, CQRS, distributed tracing (Jaeger, Zipkin), API gateways, eventual consistency, CAP theorem