← All Concepts
Architecture
Event-Driven Architecture
An architectural pattern where services communicate by producing and consuming events, enabling loose coupling and async processing.
**Core concepts:**
- **Event**: An immutable fact that something happened (e.g., "OrderPlaced")
- **Producer**: Service that emits events
- **Consumer**: Service that reacts to events
- **Event bus/broker**: Infrastructure that routes events (Kafka, SNS/SQS)
**Patterns:**
- **Event Notification**: Simple notification, consumer fetches data if needed
- **Event-Carried State Transfer**: Event contains all data needed (no callback)
- **Event Sourcing**: Store events as source of truth, derive state by replay
- **CQRS**: Separate read/write models, synced via events
**Event Sourcing detail:**
Instead of storing current state, store the sequence of events.
- "BalanceDebited $50" → "BalanceCredited $100" → replay to get current balance
- Enables: audit trail, temporal queries, rebuilding state
**Kafka** is the most popular event streaming platform:
- Topics → Partitions → Consumer Groups
- Messages are ordered within a partition
- Consumers track their offset (position in the log)
Common Use Cases
- Microservice communication without tight coupling
- Real-time analytics and data pipelines
- Audit logging and compliance (event sourcing)
- CQRS: independent read and write scaling
Advantages
- +Loose coupling between services
- +Natural support for async processing
- +Event sourcing provides complete audit trail
- +Easy to add new consumers without changing producers
Disadvantages
- -Eventual consistency (not immediate)
- -Debugging event flows is complex
- -Event schema evolution needs careful management
- -Guaranteed ordering can be challenging at scale