++++Event-Driven Architecture (EDA) is a software design pattern where decoupled components communicate through events rather than direct, synchronous calls. An 'event' is a change in state or an update, such as 'Order Placed' or 'Payment Processed'.
Event-Driven Architecture (EDA)
This content is adapted from Mastering System Design from Basics to Cracking Interviews (Udemy). It has been curated and organized for educational purposes on this portfolio. No copyright infringement is intended.
Key Characteristics
- Asynchronous Processing: Tasks happen in the background without blocking the requester.
- Loose Coupling: Producers don't need to know who the consumers are.
- Scalability: Components can be scaled or added independently.
Synchronous vs. Asynchronous Systems
Choosing between sync and async depends on the sensitivity of the operation and the need for immediate feedback.
| Feature | Synchronous (Request-Response) | Asynchronous (Event-Driven) |
|---|---|---|
| Call Type | Blocking | Non-blocking |
| Coupling | Tight coupling | Decoupled components |
| Logic Flow | Instant confirmation | Sequential/Parallel events |
| Example | Traditional HTTP APIs | Message Queues & Brokers |
Pub-Sub vs. Event Streaming
There are two primary models for distributing events: Publish-Subscribe and Event Streaming.
1. Publish-Subscribe (Pub-Sub)
Events are broadcasted to multiple subscribers. Each subscriber receives the event once and processes it.
- Example: RabbitMQ, AWS SNS.
2. Event Streaming
Events are stored as a persistent log. Consumers can read from the stream at their own pace and replay events.
- Example: Kafka, AWS Kinesis.
Key Components
- Event Producers: The source that generates the event data.
- Event Brokers: Transmit and optionally store events (e.g., Kafka, RabbitMQ).
- Event Consumers: Components that react to and process the events.
- Event Storage: Log-based persistence for replaying events.
Use Cases
- Logging & Auditing: Track system changes over time.
- Real-Time Notifications: Chat apps, stock updates, alerts.
- Microservices Decoupling: Independent scalability and fault tolerance.
- E-commerce: Flow from "Order Placed" → "Payment Processed" → "Inventory Updated."
Interview Questions & Answers 💡
1. What is EDA, and how does it differ from Request-Response?
Event-Driven Architecture (EDA) uses events for asynchronous communication.
- Decoupling: Services interact only through events.
- Scalability: New services can consume events without affecting producers.
- Flow: Traditional APIs block; EDA provides non-blocking workflows.
2. Explain the difference between Pub-Sub and Event Streaming.
- Pub-Sub: Events are transient (consumed and gone). No strict ordering. Examples: RabbitMQ, SNS.
- Event Streaming: Events are persistent and replayable. Strict ordering maintained. Examples: Kafka, Kinesis.
3. What are the key challenges of EDA?
- Eventual Consistency: Data might not be synced immediately across all tiers.
- Ordering: Ensuring events are processed in the correct sequence.
- Debugging: Tracing events across distributed services can be complex.
4. What are Dead-Letter Queues (DLQs)?
A Dead-Letter Queue (DLQ) is where failed or unprocessable messages are sent. It prevents infinite retry loops and facilitates debugging of broken events.
5. How do you make event processing idempotent?
Use unique Event IDs and maintain a "processed events" state in a database. broker-level deduplication features can also help avoid double-processing the same event.
Final Thoughts 🎯
Event-driven architecture is key to building scalable, real-time, and decoupled systems. Choosing between Pub-Sub and Streaming depends entirely on your durability and replay requirements.
What's next? Explore Multi-Tier Architecture