Inside Event-Driven Architecture

When building modern distributed backend systems especially microservices, one of the most critical design decisions you will make is how those services talk to each other. If services are too tightly coupled, your entire platform becomes fragile.

This communication between services is known as service interaction. Broadly speaking, interactions fall into two categories: synchronous (waiting for a the response) and asynchronous (firing a call and moving on).

In this blog, we’ll explore:

• Different types of service interactions.
• Dive into Event-Driven Architecture.
• Real-world patterns, use cases & types.

---

What is Service Interaction?

In a microservices architecture, multiple independent services collaborate to power an application. The communication between them is called service interaction, and it can be broadly classified into 3 types:

• Time-Driven Interaction
• Request-Driven Interaction
• Event-Driven Interaction

---

1. Time-Driven Interaction (Synchronous)

In a time driven system, actions are triggered at fixed predetermined time intervals. Think of it as cron jobs or scheduled batch processing. A service wakes up, performs its task (like generating a daily report or restoring token limits), and goes back to sleep.

For Example: Imagine you’re building an Employee Payroll Service.

• Salaries are processed once every month.
• The system runs a scheduled job (cron).
• A salary cerdit notification is generated.

---

Request-Driven Interaction (Synchronous)

This is the traditional API model. When Service A needs data or functionality from Service B, it sends a direct request (typically via HTTP or gRPC). Service A then waits for a response before it can continue the further operations.Although, it is simple to implement but the tight coupling can cause some issues. For example if Service B goes down or slow, Service A will also go down with it as it is tightly coupled (dependant on service B).

For Example: Let’s say a user places an order on your ecommerce platform.

• A user places an order.
• The Order Service sends a request to the Payment Service to process payment.
• The Order Service waits for the payment response.
• Once payment is successful, it calls the Notification Service to send confirmation. Each step depends on the previous service response if one service fails whole process goes down, making it a synchronous (request-driven) flow.

---

Event-Driven Architecture (Asynchronous)

In an Event-Driven Architecture, services communicate by generating and reacting to events. Instead of actively calling functions or waiting on other services, a service simply broadcasts that something happened.

• It's about reacting to things that happen (events), rather than directly invoking apis/function calls.
• Services are decoupled, the producer service doesn't care who consumes the event or how many consumer services there are.
• In EDA, components (services) are independent, meaning they can function without being directly communicating (tightly coupled) to one another.
• It uses Publish-Subscribe Design Pattern under the hood to carry out the communication.

---

Publish Subscribe Pattern in short:

It is a messaging paradigm in which senders (publishers) send messages message broker, which then distributes the messages to any interested receivers (subscribers) who have registered an interest in receiving those messages.

For Example: Consider a weather forecast application
A Weather Service (Publisher) publishes updates like temperature or rain alerts.

• The message is sent to a message broker.
• Multiple services subscribe to these updates:
• Forecasting Service → predicts future weather.
• History Service → stores past data.
• Maps Service → updates weather on maps.

---

Components of Event-Driven Architecture

There are majorly 5 components of an event driven architecture.

1. Events: The core unit of communication in EDA. A change in state is called an event. In an event-driven architecture, everything that happens within and to your backend system is an event for ex. a user singing up, an order created etc.. Events are emitted by sources and can encapsulate various types of information.

• The User Service emits a UserRegistered event.
• The event is sent to an Event Broker.
• The Email Service, which is subscribed to this event, receives it.
• It gets the user data and sends a welcome email to the user.
• The User Service doesn’t directly call the Email Service. It simply emits an event and carries on.

2. Event Producers (Publishers): Producers are the services responsible for emitting events (carrying out actions) when specific conditions occur. They translate system actions into enumeration messages that are consumed by other services (consumers).

For Example: Imagine a food delivery system like Zomato or Swiggy.

• The delivery partner’s phone continuously sends live location (coordinates) via websocket.
• The Delivery Management Service receives this data.
• It acts as a Producer and emits a LocationUpdated event to the event broker.

3. Event Consumers (Subscribers): Consumers listen for specific events and when a subscribed event is received by the service it triggers some internal logic based on the event.

For Example: Continuing the same food delivery system:

• The Delivery Management Service publishes LocationUpdated events.

• Multiple services subscribe to this event:

• Tracking Service → updates live location on the user’s app

• Analytics Service → analyzes delivery performance

• Restaurant Service → monitors delivery progress

These services act as Consumers which are reacting to events and performing their own tasks independently.

4. Event Broker: It is a middleware service that enables multiple services to communicate with each other through a centralized service. It routes the events between services by accepting the events from the producers and delivers them to the consumers subscribed to receive them. For example: Kafka, Rabbitmq, Redis, EventBridge etc. are used as event brokers/Message Brokers.

5. Topics: Topics Are components inside an Event-Broker. Each topic hold only certain type of events only to differentiate between the events. A publisher should know which topic it should generate the event to while consumers can subscribe to a certain topic they are interested in.

For Example:

• Producer sends an event to a topic.
• OrderPlaced → published to topic: orders.
• Broker (Kafka, RabbitMQ, etc.) stores the event under that topic.
• Consumers subscribe to the topic.
• Inventory Service and Notification Service both consume from orders topic.

---

Why Use Event Driven Architecture ? (Advantages)

Using EDA can provide you lot of advantages while building a distributed system.

• Scalable Environment: Services can scale independently.
• Loose Coupling: Services don’t directly depend on each other.
• Real-Time Processing: Events are processed as soon as they happen.
• Fault Isolation: If a consumer is down, events can be retried later from the broker.
• Cross Team Collaboration: Enables different domain teams to work together.
• Independent Testing: Testing is easy as services are independent.
• Highly Available: Event broker system can be horizontally scaled.

---

Drawbacks of EDA:

No architecture is perfect. EDA also has some trade-offs of its own.

• Event Ordering: Events may arrive out of order.
• Event Schema Updates: Over time, the structure of events will change which can break some consumers.
• Debugging: It's hard to trace end-to-end flows across asynchronous systems.
• Late Event Processing

---

Some Real Life Applications of EDA:

1. Realtime Notifications.
2. Live Chat.
3. Delivery / Cab Booking Systems (Zomato/Swiggy/Uber).
4. Unified Logging Mechanism.
5. Multiplayer Games.

---

Event-Driven Patterns in Practice

When designing how your events carry data, there are three main architectural patterns you will encounter:

• Event Notification Pattern
• Event Based State Transfer
• Event Sourcing

1. Event Notification Pattern: In event notification pattern, events are used to notify other microservices in the system that an interesting change has occurred. The notification event is small and concise (contains very less information of what has changed in state) as it only contains a reference to the state that was changed. If a consumer needs more details, it must make a synchronous call back to the source to fetch the data.

For Example: Imagine a user places an order on an e-commerce platform. The Order Service creates the order and publishes an OrderPlaced event.

• The event is sent to the Event Broker.
• Multiple services subscribe to this event.
• Inventory Service → fetches order details and updates stock.
• Shipping Service → fetches order details and initiates delivery.

The event only contains basic information (like orderId), and consumers fetch additional data themselves.

Example Event:

{
  "eventType": "OrderPlaced",
  "eventVersion": "1.0",
  "timestamp": "2025-07-07T14:00:32Z",
  "eventId": "b3d9f76a-18f2-4e34-a820-7d5f2e0b8212",
  "source": "order-service",
  "data": {
    "orderId": "ORD123456",
    "userId": "USR7890",
    "orderStatus":"Preparing_Order"
  }
}

---

2.Event Based State Transfer: In this architectural pattern events are used to propagate state changes between services in an event-driven architecture. Instead of relying on synchronous request/response patterns the state updates are directly sent inside the event information.**
For Example: Imagine a user places an order on an e-commerce platform. The Order Service creates the order and publishes an OrderPlaced event.
Unlike notification pattern, this event contains complete order details like orderId, items, quantity, shipping address etc.

Consumers do not need to call Order Service as they already have all required data.

Example Event:

{
  "eventType": "OrderPlaced",
  "eventVersion": "2.1",
  "timestamp": "2025-07-07T14:05:00Z",
  "eventId": "8fc67c8d-921c-443a-a67a-b3aefaed3384",
  "source": "order-service",
  "data": {
    "orderId": "ORD123456",
    "status": "Not_Shipped",
    "items": [
      { "productId": "P001", "quantity": 2 },
      { "productId": "P002", "quantity": 1 }
    ],
    "shippingAddress": {
      "city": "Hyderabad",
      "pincode": "000001"
    }
  }
}

3. Event Sourcing: The Event Sourcing Pattern is a way to store data by recording every change as a sequence of events, instead of just saving the latest state. Event Sourcing records every single change which is immutable. If any failure occurs in the system the it can rebuild the current state at by using these event records any point in time.

---

Conclusion: Event-Driven Architecture is not just a design pattern. It’s a paradigm shift in how systems think and communicate. The goal is not to eliminate synchronous communication but to use the right approach at the right place.

I Hope now you have a better understanding of the Event-Driven Architecture, it's components and types.

If you like the content please share it with your friends, colleagues, and coding buddies. Have a nice day ❤️