Theory
Event-Driven Architecture (EDA)
📋 Overview
Event-Driven Architecture (EDA) is a design pattern where services communicate asynchronously through the production and consumption of "events." An event represents a significant change in state (e.g., "OrderPlaced"). Unlike traditional Request-Response (REST), EDA decouples the producer from the consumer, allowing for highly scalable and resilient distributed systems.
🏗️ Core Principles & Characteristics
- Producers & Consumers: Producers emit events without knowing who will consume them. Consumers subscribe to events they are interested in.
- Asynchronous Communication: Services don't wait for a response, preventing "blocking" and reducing latency in the main user flow.
- Event Broker: A middleware (Kafka, RabbitMQ, SNS/SQS) that handles the routing, persistence, and delivery of events.
- Loose Coupling: Services are independent; changing a consumer doesn't require changes to the producer.
- Scalability: Services can scale independently based on the volume of events they process.
⚖️ Trade-offs: Pros & Cons
- Pros:
- Resilience: If a consumer is down, events are queued in the broker and processed when it returns.
- Flexibility: New features (e.g., an Analytics service) can be added by simply subscribing to existing events.
- Responsiveness: Long-running tasks (emailing, image processing) happen in the background.
- Cons:
- Complexity: Harder to trace a request across multiple services ("What triggered this?").
- Consistency: Moves from Strong Consistency to Eventual Consistency.
- Duplicate Events: Requires consumers to be idempotent.
🌍 Real-World Implementation
- E-commerce: Placing an order triggers "OrderPlaced," which is then consumed by Payment, Inventory, and Shipping services independently.
- Netflix: Uses events to update user watch history, recommendations, and billing across thousands of microservices.
- Uber: Real-time event streams for driver locations, pricing updates, and ride matching.
💡 Interview "Gotchas" & Tips
- Idempotency: Crucial! If a network error causes an event to be sent twice, the consumer must ensure the action (e.g., charging a card) only happens once.
- Event Ordering: Message brokers like Kafka only guarantee ordering within a partition.
- Dead Letter Queues (DLQ): Where do events go if a consumer fails repeatedly? (Answer: DLQ for manual inspection).
- Saga Pattern: How do you handle distributed transactions in EDA? (Answer: Use a series of local transactions and compensating events).
📐 Suggested Architecture Primitives
- Message Brokers: (Apache Kafka, RabbitMQ, AWS SNS/SQS).
- Event Stores: (EventStoreDB) for Event Sourcing patterns.
- Webhooks: For external event notifications.
Canvas