Event-Driven Architecture (EDA)
Event-Driven Architecture is a software architecture paradigm promoting the production, detection, consumption of, and reaction to events. Instead of services calling each other directly (like in REST), they communicate by emitting and listening for events.
1. Core Concepts
- Event: A significant change in state (e.g., "Order Placed", "User Registered"). It is immutable and happened in the past.
- Producer (Publisher): The service that detects the event and sends it out. It doesn't know who (if anyone) is listening.
- Consumer (Subscriber): The service that listens for specific events and reacts to them.
- Event Channel (Broker): The middleware (like RabbitMQ, Kafka, AWS SNS/SQS) that transmits events from producers to consumers.
2. Communication Models
Pub/Sub (Publish-Subscribe)
The messaging infrastructure keeps track of subscriptions. When an event is published, it sends a copy to every subscriber interested in that event type.
Event Streaming
Events are written to a log (like Apache Kafka). Consumers read from the log at their own pace. This allows for "replaying" events to rebuild state or fix bugs by reprocessing past data.
3. Benefits
- Decoupling: Producers and consumers don't need to know about each other. You can add a new consumer (e.g., a new Analytics Service) without touching the Producer code.
- Scalability: You can scale consumers independently if the queue gets backed up.
- Resilience: If a consumer goes down, the events persist in the queue until the consumer comes back online.
4. Challenges
- Complexity: Harder to trace the flow of execution compared to a linear request/response.
- Eventual Consistency: Data might not be consistent across all services immediately. The system is "eventually" consistent.
- Debugging: Requires specialized tools (distributed tracing) to follow an event's journey across multiple services.
programming/microservices-architecture programming/asynchronous-programming programming/domain-driven-design