Event Driven Architecture (EDA)

Introduction

• EDA is becoming central in modern software design due to:
  • Rise of microservices
  • Big data
  • Real-time processing
• Companies require scalable and flexible methods to manage interactions between components.

Problems with Traditional Request-Response Model

• As applications grow:
  • Traditional request-response model becomes inefficient.
  • Example: Service A requests data from Service B.
• Managing interactions becomes complex:
  • Each interaction requires defined requests and responses.
  • Complexity increases exponentially with more services.
  • Tightly coupled interactions hinder scalability and evolution.
• Disruptions occur when introducing/updating services.

Benefits of Event Driven Architecture

• EDA provides a streamlined alternative by:
  • Decoupling services through events.
  • Offering scalable, flexible, and efficient designs.
• Core of EDA:
  • Services communicate through generation, propagation, and consumption of events.
  • Event: Signal indicating significant occurrence (e.g., user click, order placed).

Components of Event Driven Architecture

• Event Producers:
  • Components that generate events.
  • Example: In e-commerce, order service produces events like "Order Placed" or "Payment Completed".
• Event Consumers:
  • Components that respond to events.
  • Example: Inventory service consumes "Order Placed" to manage stock.

Case Studies

1. Netflix

• Handles over a billion events daily.
• Uses EDA for:
  • Streaming data analytics
  • Recommendations
  • Error handling
• Events generated for user actions (e.g., starting a show) are consumed by services like the recommendation engine.
• Monitors service health and alerts engineers if an issue arises.

2. Uber

• Manages millions of rides globally using EDA.
• Example Workflow:
  • User requests ride ➔ "Ride Requested" event produced.
  • Multiple services consume this event (e.g., matching service, ETA service, pricing service).
• Collects real-time traffic data for optimizing routes.

Comparing with Other Architectures

• EDA vs. Service Mesh
  • EDA focuses on asynchronous communication.
  • Service mesh manages synchronous communications.
• Both can work together for complex systems.

Scalability and Processing Styles

• Scalability is a key reason for adopting EDA:
  • Producers and consumers can scale independently.
• Two processing styles:
  • Simple Event Processing:
    • Triggers straightforward actions (e.g., updating stock).
  • Complex Event Processing:
    • Aggregates multiple events for advanced decision-making (e.g., pricing adjustments).

Key Components in Designing EDA

1. Event Producers: Microservices generating events.
2. Event Broker: Intermediary for managing event queues (e.g., Kafka, RabbitMQ).
3. Event Consumers: Services that take action based on events.
4. Event Types and Contracts: Define event structure (e.g., order ID, payment status).

Challenges of EDA

• Ensuring correct order of event processing can be difficult.
• Risk of reprocessing events causing duplicate actions (e.g., payment processing).
• Managing eventual consistency across services requires careful planning.

Tools for Building EDA Systems

• Apache Kafka:
  • Scalable messaging platform for real-time data streaming (used by companies like LinkedIn, Uber).
• AWS Messaging Services:
  • Cloud-based options ideal for EDA.
• RabbitMQ:
  • Lightweight messaging broker suitable for smaller systems.

Conclusion

• EDA is integral for systems managing billions of events daily, enhancing scalability and efficiency.