Event-Driven Architecture Core Knowledge
Full Reference: See advanced.md for Saga implementations (Node.js, Java), Outbox pattern implementations, Event Sourcing, CQRS, and idempotency patterns.
Deep Knowledge: Use mcp__documentation__fetch_docs with technology: event-driven for comprehensive documentation.
When NOT to Use This Skill
-
Monolithic applications - Use simple in-process events
-
Simple CRUD operations - Use REST APIs or GraphQL
-
Real-time UI updates - Use WebSockets or SSE
-
Synchronous workflows - Use traditional transactions
Architecture Patterns Overview
Pattern Purpose Complexity
Pub/Sub Decouple producers from consumers Low
Event Sourcing Store state as event sequence High
CQRS Separate read/write models Medium-High
Saga Distributed transactions High
Outbox Reliable event publishing Medium
Saga Pattern
Manages distributed transactions across services without 2PC.
Choreography Saga
┌─────────┐ event ┌─────────┐ event ┌─────────┐ │Order Svc│────────────▶│Payment │────────────▶│Inventory│ └─────────┘ │ Svc │ │ Svc │ ▲ └─────────┘ └─────────┘ │ compensate │ compensate │ └───────────────────────┴───────────────────────┘
Orchestration Saga
┌─────────────┐
│ Saga │
│Orchestrator │
└─────────────┘
/ | \
▼ ▼ ▼
┌───────┐ ┌───────┐ ┌───────┐
│Order │ │Payment│ │Invent.│
└───────┘ └───────┘ └───────┘
Transactional Outbox Pattern
Ensures reliable event publishing with database transactions.
┌────────────────────────────────────────────┐ │ Database Transaction │ │ ┌──────────────┐ ┌──────────────────┐ │ │ │ Business │ │ Outbox Table │ │ │ │ Table │ │ (messages) │ │ │ └──────────────┘ └──────────────────┘ │ └────────────────────────────────────────────┘ │ Polling Relay / CDC │ ┌─────────────────┐ │ Message Broker │ └─────────────────┘
Outbox Table Schema
CREATE TABLE outbox ( id UUID PRIMARY KEY, aggregate_type VARCHAR(255) NOT NULL, aggregate_id VARCHAR(255) NOT NULL, event_type VARCHAR(255) NOT NULL, payload JSONB NOT NULL, status VARCHAR(50) DEFAULT 'PENDING', created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );
CQRS Architecture
Commands Queries
│ │
▼ ▼
┌───────────────┐ ┌───────────────┐
│ Command Model │ │ Query Model │
│ (Write) │ │ (Read) │
└───────────────┘ └───────────────┘
│ ▲
▼ │
┌───────────────┐ Events ┌───────────────┐
│ Write Store │───────────────▶│ Read Store │
└───────────────┘ └───────────────┘
Anti-Patterns
Anti-Pattern Why It's Bad Solution
Event Soup Too many fine-grained events Design coarse-grained domain events
Missing Idempotency Duplicate processing Add idempotency keys
No Compensation Logic Failed saga can't rollback Implement compensating transactions
No Dead Letter Queue Failed events lost Configure DLQ for error handling
Weak Event Ordering Race conditions Use partitioning or ordered queues
Quick Troubleshooting
Issue Diagnostic Solution
Lost events Check message broker Implement Outbox pattern
Duplicate processing Logs show multiple executions Add idempotency checks
Saga stuck Compensation not triggered Add timeout handling
Growing DLQ Many failed messages Analyze failures, fix consumers
Slow event processing High message lag Scale consumers, optimize handlers
Best Practices
Message Design
-
Include correlation ID for tracing
-
Version your events for evolution
-
Keep payloads small, reference large data
Error Handling
-
Implement retry with exponential backoff
-
Use Dead Letter Queues for failed messages
-
Set up alerting on DLQ growth
Monitoring
-
Track message lag
-
Monitor consumer group health
-
Alert on processing errors
-
Trace message flow across services
Reference Documentation
Available topics: patterns , saga , outbox , cqrs