Lecture 201: Introduction to Event-Driven Architecture (EDA)

Imagine you're at a theater performance. An actor on stage delivers a monologue expressively, and the audience reacts with applause — that's events in action. What we call events are key moments that "flip" the state of a system.

In the case of Event-Driven Architecture, applications are designed to react to events instead of spinning in a tight request-response loop. This is an architecture where events act as triggers to perform actions or change states in the system.

Differences from traditional architecture

Traditional architecture, like REST API, is like a phone call: the client calls the server, the server answers. But what if the server is busy? You'll have to wait. In EDA this process is asynchronous: the client "shouts" its request into a public microphone (a Kafka topic), and someone will pick it up.

We can highlight a few key differences of EDA:

• Asynchronicity: events are created and processed independently of each other.
• Loose coupling: components don't rely on direct calls to each other.
• Reactivity: each component reacts to incoming events.

Main components of EDA

EDA is built on three main components:

1. Events: these are key changes or important actions in the system. For example, "user registered" or "payment confirmed".
2. Producers: components that initiate events. In our app this could be the order-processing microservice that creates a "new order" event.
3. Subscribers: components that listen for events and react to them. For example, the notifications microservice that sends an e-mail "Thank you for your order!".

Event stream

When people talk about an event stream, you can imagine it like a metaphorical waterfall. The whole system "listens" to that stream and processes the "drops" (events) as they arrive. To manage this we use a message broker — an intermediary between producers and subscribers. Apache Kafka can act as such a broker.

Benefits of Event-Driven Architecture

EDA isn't just a trendy acronym from the IT world. Imagine a large modern house where all systems react to what's happening. A motion sensor detects someone entering a room — and the lights turn on automatically. The temperature drops below the set point — the heating kicks in. A smoke detector senses smoke — and the fire suppression system triggers instantly.

In traditional architecture each system has to constantly ask others: "What's changed with you?". That's like checking every minute whether it's time to turn the lights or heating on. In an event-driven architecture systems just react to what happens as soon as they get the signal.

Want to add a new system, like automatic blinds? Just hook them up to the shared network of sensors, and they'll start reacting to light-level or time-of-day events right away. That's scalability — new components are easy to add without reconfiguring the rest.

If some system fails, for example the automatic blinds stop working, the rest of the house keeps functioning. When they're fixed, they automatically sync with the current house state — that's fault tolerance. At the same time you can update each system independently: replacing the motion sensors won't affect the climate control (loose coupling).

And it's fast! As soon as a sensor detects an event, all related systems react instantly. No polling, no constant checks — just immediate reaction to important events. It's this reactive behavior (reactivity) that makes event-driven architecture

especially attractive for modern systems.

Use cases for EDA

EDA becomes an integral part of many modern systems. Here are some real examples:

• E-commerce: events like "new order", "item delivered", "user left a review" trigger actions such as updating inventory, showing ratings, and sending notifications to the customer.
• Social networks: when you hit like, an event is generated and your friend receives a notification.
• Transaction processing: in financial systems events help track changes in payment status.

How the event stream works

Here's an example to solidify the idea. Suppose our store processes orders. A typical interaction:

1. A customer places a new order.
2. The orders microservice publishes an OrderCreated event to a Kafka topic.
3. Subscribers pick up that event:
   • "Delivery microservice" schedules the delivery.
   • "Notifications microservice" sends a confirmation e-mail to the customer.
   • "Inventory microservice" updates stock quantities.

Apache Kafka as a message broker

Apache Kafka, as we already know, is an event broker that helps deliver events from the "main actor" to the "audience". Kafka makes processing faster, offloading heavy tasks and ensuring high reliability.

Real-world cases

• Amazon widely uses EDA so that order processing and product information updates happen instantly. For example, when a customer adds an item to the cart, an event is sent to the message broker, and other services see the info right away.
• Netflix uses EDA to manage recommendations. Your choice of the next movie becomes an event that triggers updating your personalized recommendations.

How we'll apply EDA

In this course we'll build real applications that use events to manage different processes. You'll learn to design events, write producers and subscribers, and work with Apache Kafka.

Practical EDA scheme

Example events:

• UserRegistered: when a user registers in the system.
• OrderPlaced: when a new order is made.
• PaymentProcessed: when a payment is successfully completed.

Design example:

1. Creating events: define the data structure that the event carries.
2. Publishing an event: the component that creates the event.
3. Handling the event: the service that "listens" for the event and performs an action (for example, sending an e-mail).

Example of an event JSON structure:

{
   "eventId": "12345",
   "eventType": "OrderCreated",
   "createdAt": "2023-10-01T12:00:00Z",
   "data": {
      "orderId": "54321",
      "customerId": "98765",
      "orderAmount": 250.00
   }
}

Next steps

Now that you've been introduced to the basics of event-driven architecture, we'll dive deeper into the principles of asynchronous communication and start designing our first events. Get ready — there's a lot of interesting stuff ahead!