Event-Driven Architecture
A software design pattern where components communicate by producing and consuming events, enabling loose coupling and asynchronous processing.
Detailed Explanation
In event-driven architecture, components emit events (facts that something happened) without knowing who consumes them. Consumers react to events asynchronously. This decouples producers from consumers—adding new consumers doesn't require changing the producer.
Event-driven patterns include: Event Sourcing (storing state changes as events), CQRS (separating read and write models), Pub/Sub (publish-subscribe messaging), and Event Choreography (services react to events independently). Message brokers (RabbitMQ, Kafka, SQS) enable event-driven communication between services.
Why It Matters
Event-driven architecture enables loose coupling, scalability, and flexibility. It is the natural choice for microservices that need to communicate without tight dependencies.
Real-World Example
When a user places an order, the OrderService emits an OrderPlaced event. The InventoryService reserves stock, the PaymentService charges the card, and the NotificationService sends a confirmation email—all independently reacting to the same event.
When to Use
When you need loose coupling between services, asynchronous processing, event sourcing, or when multiple services need to react to the same occurrence.
Advantages
- Loose coupling between services
- Asynchronous processing improves performance
- Easy to add new consumers
- Natural fit for microservices
- Supports event sourcing and CQRS
Disadvantages
- Debugging is harder (no clear call stack)
- Eventual consistency challenges
- Event ordering can be complex
- Testing requires mocking message brokers
- Event schema evolution is challenging
Related Terms
Frequently Asked Questions
What is the difference between events and commands?
Events are facts that something happened (OrderPlaced). Commands are requests to do something (PlaceOrder). Events are broadcast; commands are directed. Events enable loose coupling; commands imply direct control.
What is Event Sourcing?
Event Sourcing stores all state changes as a sequence of events instead of current state. The current state is derived by replaying events. It provides a complete audit log, enables time travel, and supports debugging.
What is the difference between Kafka and RabbitMQ?
Kafka is a distributed event streaming platform (high throughput, persistent, replayable). RabbitMQ is a traditional message queue (flexible routing, protocol support, simpler). Kafka for event streaming; RabbitMQ for task queues.
How do I handle event schema evolution?
Use schema registries (Confluent Schema Registry), version events (include version in the event), design for backward compatibility (add optional fields), and use consumer-side transformation for new versions.
When should I NOT use event-driven architecture?
For simple applications with few services, when you need synchronous responses, when debugging simplicity is critical, or when team experience with distributed systems is limited. Start simple; add events when needed.