Event Driven Architect

---
name: Event Driven Architect
description: Use when designing event-driven systems: event sourcing, CQRS, message queues, and distributed communication.
category: Engineering
version: 1.0.0
tools: []
---

# Event-Driven Architecture

Design loosely coupled systems using events as primary communication.

## Event Sourcing Fundamentals

- Identify aggregate boundaries. Each owns an append-only event stream.
- Events are immutable facts (past tense): OrderPlaced, PaymentReceived, ItemShipped.
- Event store: append-only log, never update or delete. Corrections = compensating events.
- Rebuild current state by replaying from stream. Use snapshots every 100-500 events.
- Version events explicitly. Use upcasters for schema evolution during replay.

## CQRS Implementation

- Separate write model (event store) from read model (optimized projections).
- Build projections per query pattern. Single event stream → multiple read models.
- Accept eventual consistency. UI must handle propagation delay.
- Command DB: event store. Query DB: PostgreSQL, Elasticsearch, Redis (best fit per pattern).
- Process projections idempotently. Same event twice = identical result.

## Message Queue Architecture

- Technology by guarantees: Kafka (ordered durable), RabbitMQ (flexible routing), SQS (managed), NATS (low-latency pub/sub).
- Topics by business domain: `orders.events`, `payments.events` (not `database.changes`).
- Consumer groups for horizontal scaling. Each group processes topic partitions.
- Dead letter queues for failed messages after retry count exceeded.
- Monitor DLQ depth and message TTL. Non-consumed messages = system health issue.

## Event Standards

- Every event: eventId, eventType, aggregateId, timestamp, version, correlationId, causationId.
- Use correlationId to trace chains back to originating command.
- Keep events small: only changed data, not entire state.
- Define schemas: JSON Schema, Avro, Protobuf. Register in schema registry, validate on publish.
- Distinguish domain events (business state changes) from integration events (cross-service).

## Saga and Process Manager Patterns

- Sagas coordinate long-running processes across aggregates/services.
- Implement compensating actions for every step. Failure at step 3 → rollback steps 2, 1.
- Process managers for complex coordination. Subscribe to events, issue commands.
- Store saga state durably. Failure recovery resumes from last known state.
- Set timeouts on steps. No response within timeout → trigger compensation.

## Operations

- Monitor event lag: difference between latest published and latest consumed per consumer group.
- Alert when lag exceeds threshold. Growing lag = consumer cannot keep up.
- Replay events safely for rebuilding projections or debugging (must be idempotent).
- Archive old events to cold storage once no longer needed for active replay.