Event Driven Architecture (EDA)

---

Event Driven Architecture is a design pattern where software components interact by producing and consuming events — changes or actions happening within a system.

1. Categories of Event Driven Architecture

• Event Producer:
  The one who announces something happened.
  Example: A person pressing a doorbell button.

• Event Channel:
  The messenger that carries the announcement to whoever needs to hear it.
  Example: The doorbell wire or wireless signal.

• Event Consumer:
  The listener that reacts when the announcement is heard.
  Example: The chime that rings when the doorbell is pressed.

💡 Example in everyday life:
A smoke detector (Producer) senses smoke → sends an alert signal (Channel) → your phone (Consumer) receives and displays a notification.

---

Example: Smoke Detector — Multiple Consumers in an Event Driven Architecture

Scenario

Suppose you have a modern smart home setup. The Smoke Detector acts as the Event Producer by generating a “Smoke Detected” event.

But instead of just one device reacting, multiple consumers handle the event based on their needs:

How EDA Enables This:

• Each consumer subscribes to the “Smoke Detected” event.

• The event may be delivered via various channels (mobile notification, direct device connection, cloud).

• All consumers act independently, with no direct link to each other or to the producer.

• If a new service (for example, a neighbor alert system) needs to be added, it can simply subscribe to the same event—no changes needed in the smoke detector or existing consumers.

Key takeaway:

In EDA, a single event (like "Smoke Detected") can trigger different actions in multiple places, all tailored to their unique requirements.

This is a major advantage over traditional setups, where only a single, fixed consumer might use the information (for example, only a chime rings when the doorbell is pressed).

---

2. Categories of Event Driven Architecture

• Event Producers:
  Components or services that detect system state changes or user actions and publish them as events.

• Event Channels:
  Middleware or messaging infrastructure that routes events asynchronously from producers to consumers, ensuring the two remain decoupled.

• Event Consumers:
  Services or components that subscribe to events and trigger specific workflows or actions in response.

---

How Event Driven Architecture (EDA) Works Internally

Event Driven Architecture is designed around the generation, detection, and handling of events—significant changes or actions within a system. Internally, EDA consists of several key components and flow mechanisms working together seamlessly:

Key Internal Components

• Event Source (Producer):
  The component or system that generates events, such as user actions, sensor detections, or state changes. For example, a user clicking a button or a sensor detecting temperature rise.

• Event:
  A message or data packet that describes what happened. It typically includes metadata like timestamp, type of event, and payload (details).

• Event Broker / Event Bus:
  Acts as the central hub that transports and routes events from producers to consumers. It decouples event producers from consumers, enabling asynchronous communication and scalability.

• Publisher:
  A part of the event source that emits events onto the event bus.

• Subscriber (Consumer):
  Components that express interest in certain event types and listen for them on the event bus to take appropriate action when they occur.

• Event Handler:
  Code or logic within subscribers that processes received events, executing business rules or triggering workflows.

• Event Router / Dispatcher:
  Routes events to the correct subscribers based on event type or other criteria to ensure relevant handling.

• Aggregator:
  Combines multiple related events into a single comprehensive event to simplify processing.

• Event Store:
  A persistent log of all events for auditing, debugging, or replaying events to restore system state.

How the Flow Works

1. Event Generation:
   An event source detects a change or action and creates an event.

2. Event Publishing:
   The event is published to the event broker or event bus.

3. Event Routing:
   The event bus routes the event to all interested subscribers based on their subscriptions.

4. Event Handling:
   Subscribers receive the event and execute their associated event handlers, which may trigger further actions or generate new events.

5. Event Storage (Optional):
   Events may be stored in an event store for future reference, replay, or audit purposes.

6. Feedback and Continuation:
   Depending on design, event processing may cause more events to be generated, creating a dynamic and loosely coupled chain of interactions.

Benefits of This Internal Design

• Loose Coupling: Producers and consumers do not depend on each other, enabling independent development and deployment.

• Scalability: Components scale independently as needed.

• Resilience: Failures in one component do not block others; events can be queued and replayed.

• Real-Time Processing: Enables immediate responses to state changes or external inputs.

---

This internal working model of EDA provides the foundation for building scalable, flexible, and maintainable real-time systems.

---

3. Real-World Service Examples Using Event Driven Architecture

• E-commerce Order Processing:
  When an order is placed, an event triggers payment processing, inventory update, and shipping scheduling independently and asynchronously.

• Ride-Sharing Platforms (like Uber):
  Events such as "Ride Requested" from passenger apps are published to event brokers, which notify driver apps and dispatch services to act in real-time.

• Retail Banking:
  Real-time communications between transaction systems, payment gateways, and fraud detection use events to process operations quickly and reliably.

• IoT Sensor Data Processing:
  Devices generate events about environment changes which are streamed and instantly processed by subscribed services for monitoring or alerting.

• Streaming Services (e.g., Netflix):
  Uses Apache Kafka for event streaming to handle content finance management, data synchronization, and scalable microservices coordination.

---

4. Common Tools & Technologies for Implementing Event Driven Architecture

---

Difference Between Request/Response Architecture and Event-Driven Architecture (EDA)

---

Benefits of Using Event-Driven Architecture (EDA)

• Loose Coupling and Decoupling:
  Event producers and consumers operate independently, reducing dependencies and making the system more flexible and easier to maintain.

• Scalability:
  EDA supports horizontal scaling naturally by adding more producers or consumers without impacting others, enabling the system to handle large workloads efficiently.

• Fault Tolerance and Resilience:
  If one service fails, others continue functioning. The event broker buffers events and delivers them once services recover, improving availability.

• Fan-Out and Reduced Technical Debt:
  Events can be fanned out to multiple consumers without custom polling, saving resources like network bandwidth and computing power.

• Modularity and Flexibility:
  Components can be developed, deployed, and scaled independently, which accelerates development cycles and simplifies upgrades.

• Extensibility and Integration:
  Easy to connect with third-party systems and add new functionalities via event notifications, supporting rapid evolution of systems.

• Asynchronous Processing:
  Enables handling many events concurrently without blocking, improving overall system performance and user experience.

• Improved Analytics and Auditing:
  Event logs provide a chronological record for debugging, monitoring, compliance, and operational insights.

• Real-Time Responsiveness:
  Systems react to events as they happen with low latency, enabling immediate actions, real-time analytics, and faster decision-making.

---

How Event Driven Architecture (EDA) Works with Apache Kafka

Apache Kafka is a popular distributed event streaming platform that acts as the backbone for event-driven architectures by enabling real-time, scalable, and reliable event communication between producers and consumers.

Kafka EDA Flow

1. Event Producer creates an event:
   A service or app produces an event message (e.g., order placed).

2. Event is published to a Kafka topic:
   Topics are logs that store ordered event streams.

3. Kafka Broker stores events:
   The Kafka cluster manages persistence, replication, and delivery of events.

4. Multiple consumers subscribe to topics:
   Consumers read and process relevant events at their own pace.

5. Consumers act on events asynchronously:
   They trigger workflows, update databases, send notifications, etc.

6. Stream processing (optional):
   Kafka Streams or ksqlDB can transform and aggregate events in real-time.

7. Event replay and audit:
   Events remain stored for a configurable time to reprocess or analyze later.

---

Key Kafka Components in EDA

• Producer: Publishes events to Kafka topics.

• Topic: A durable, partitioned log of events.

• Broker: Kafka server that serves topics and replicates data.

• Consumer: Reads and processes events from topics.

• Consumer Group: A set of consumers sharing the load of reading from a topic.

• Kafka Streams: Library for processing event data in motion.

---