What is Event-Driven Architecture? How is it structured and how does it work?

Question

IT Interview Practice · Accepted Answer

**Event-Driven Architecture (EDA) organizes work around events: messages describing something that has already happened.** For example, after an order is accepted, other components can react to `OrderPlaced` without the order component calling each one individually.

The central idea is to separate recording a fact from the different actions that follow it. This can happen inside one application or across services. It does not require microservices or guarantee immediate processing. [AWS explains this producer–consumer relationship](https://aws.amazon.com/event-driven-architecture/).

## 1. Which parts are involved?

- **Producer:** records an action and publishes an event. Here, the order component announces an accepted order.
- **Event:** contains the fact and identifiers needed to interpret it, such as event ID, order ID and time.
- **Consumer:** reacts to an event it understands. The email consumer sends a confirmation; the reporting consumer updates sales figures.
- **Delivery channel:** carries the event. Within one process, this might be an event dispatcher. Between services, a broker can receive, store and distribute messages according to its configuration.

The diagram below uses a broker with a separate subscription for each consumer:

```text
Customer -> Orders -> Orders database
               |
               | OrderPlaced(orderId=42, eventId=e1)
               v
             Broker
               |----------> Email
               |----------> Reporting
```

Email and Reporting each need their own copy of the event. Workers sharing one queue commonly divide its messages among themselves; that setup alone does not broadcast every message to both functions. See [the Publisher–Subscriber pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/publisher-subscriber).

## 2. Follow one order from input to result

Suppose a customer places order 42:

1. **Orders validates and saves the order.** It returns the accepted order ID. This response does not claim that the email has already been sent.
2. **Orders makes `OrderPlaced` available for delivery.** The message describes the completed action; it is different from a command asking a particular service to do something.
3. **Email receives the event** and sends the confirmation. **Reporting receives its copy** and includes order 42 in its figures.
4. The customer sees the accepted order first. The email and updated report can appear later, because these tasks run independently.

If Email is temporarily unavailable, a durable delivery setup can retain its message and retry later. Reporting can still progress. This depends on configured retention, acknowledgements and retry behavior; the architectural label itself does not provide them.

## 3. What must be handled when something fails?

The original order and its notification must not silently diverge. One approach is an **outbox**: save the order and a pending event in the same database transaction, then let a background process deliver that event.

Delivery can repeat. A consumer therefore needs **idempotent handling**, meaning processing the same event again does not repeat its business effect. For email, a sent marker alone still has a failure window around the external send; use the provider's idempotency support where available or explicitly handle that limitation.

Also define what happens to repeatedly failing messages, preserve an order identifier for tracing, and check whether events for the same order must be processed in sequence. These are core [EDA design considerations](https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven).

## 4. When is EDA a useful choice?

**Benefits:** add a new reaction without adding another direct call to Orders; let slow tasks run separately; absorb temporary bursts when the delivery system has suitable buffering.

**Costs:** the complete workflow is spread across components. You must monitor delayed processing, failed deliveries and changing event formats. A queue can postpone overload, but it cannot remove an unlimited backlog.

Use EDA for independent reactions such as notifications, analytics or background processing. For a small operation that must return one immediate, consistent result, a direct call or local transaction is often simpler. **EDA describes how components react; Event Sourcing describes how authoritative data is stored.** The two can be combined, but neither requires the other.

1. Which parts are involved?

2. Follow one order from input to result

3. What must be handled when something fails?

4. When is EDA a useful choice?

Related questions