Event-Driven Architecture
An architectural approach based on the generation and processing of events to decouple and make systems responsive.
Classification
- ComplexityMedium
- Impact areaTechnical
- Decision typeArchitectural
- Organizational maturityIntermediate
Technical context
Principles & goals
Use cases & scenarios
Compromises
- Event loss during system failures
- Difficulties in tracing events
- Complexity in integrating components
- Clearly define and document events
- Use scalable infrastructure
- Regularly review event processing
I/O & resources
- Events from users or systems
- Configuration settings for event processing
- Data sources for events
- Processed events
- Notifications or alerts
- Analytical reports
Description
Event-Driven Architecture (EDA) is an architectural approach that focuses on the generation, transmission, and processing of events. In EDA systems, components communicate through events generated by an event emitter and processed by one or more event handlers. This approach promotes decoupling of components and enables a responsive, scalable, and flexible system architecture.
✔Benefits
- Increased flexibility and adaptability
- Improved scalability
- Faster response times
✖Limitations
- Complexity in error handling
- Higher demands on system architecture
- Potential issues with consistency
Trade-offs
Metrics
- Response Time
The time taken to respond to an event.
- Throughput
The number of events processed per unit of time.
- Error Rate
The percentage of erroneous events.
Examples & implementations
E-Commerce Order System
An e-commerce system that processes orders through events to ensure a responsive user experience.
Financial Transaction Processing
A system that processes financial transactions in real-time and uses events to update account balances.
Social Media Notification System
A notification system that uses events to inform users about new interactions.
Implementation steps
Design the event processing system
Integrate event sources
Set up monitoring and maintenance
⚠️ Technical debt & bottlenecks
Technical debt
- Insufficient documentation of events
- Outdated event processing logic
- Lack of tests for event processing
Known bottlenecks
Misuse examples
- Ignoring events that are important for processing
- Not properly validating events
- Not processing events in the correct order
Typical traps
- Assuming all events are equally important
- Overlooking errors in event processing
- Underestimating the complexity of system integration
Required skills
Architectural drivers
Constraints
- • Event processing must be reliable
- • Events must be processed in the correct order
- • Systems must be scalable