What is Event Driven Architecture and why we need it?
When systems start reacting to events instead of directly calling each other, a different architectural style emerges — Event Driven Architecture. So in Event driven architecture center part is Event. All applications are triggering one or more events in real time scenario, but we never recognize it. So, Let’s try to understand Event driven architecture and why we need.
1. What Is Event Driven Architecture (EDA)?
“An event represents a fact that something has happened in the business domain at a specific point in time.
It captures the state change of an entity and is immutable in nature.
Once an event occurs, it may trigger one or more side effects in the system.”
Key points to emphasize:
Event = fact, not command
Happens in the past
Immutable
Represents state change
Can have multiple consequences
Example-1:
For example, A user is registered in the system can be one of the events. This event can be called as a UserRegiseredEvent. In effect of this event triggered system will perform certain tasks. Like sending a welcome email to registered user. Creating certain database entries needed for the system.
User Registration Example
You already did this well — just organize it:
Event: UserRegistered
What changed: A new user now exists
Possible reactions:
Send welcome email
Create user profile
Assign default role
Trigger onboarding workflow
The user registration itself does not care who reacts to it.
Example-2:
Similarly let’s take an example of another event called in an e-commerce system. Order is placed we have OrderPlacedEvent.
Keep it parallel to the first example:
Event: OrderPlaced
What changed: An order moved from “non-existent” to “placed”
Consumers:
Inventory service
Payment service
Notification service
Analytics service
2. Why we need an Event Driven Architecture ?
Real business applications are normally medium to large size. In these applications we can have various complex business flows. To handle all of this flow asynchronously and non-blocking way we might need an event driven architecture. EDA helps systems to scale, flexible as new business requirements are coming in.
While reading this article you may have a question, Why Traditional Rest approach does not work?
Let’s take an example of Order Placed as we described above.
In Traditional REST approach we have below flow.
Order Service
├─ calls Payment Service
├─ calls Inventory Service
├─ calls Email Service
├─ calls Invoice Service
└─ calls Analytics Service
What goes wrong?
- If one service is slow, the order fails
- If one service is down, everything breaks
- Adding a new feature means changing Order Service
- Scaling becomes painful
- Debugging becomes scary
So Traditional REST Communication has below problems.
1. REST creates tight coupling
Service A must know Service B
Failures cascade: Explain it
Synchronous blocking: Explain it
Get AhesanAli Suthar’s stories in your inbox
Join Medium for free to get updates from this writer.
2. Scalability pain
One API call → many downstream calls
Latency increases: Explain it
Retries complicate logic: Explain it
3. Change amplification
Adding a new consumer = modifying existing services
Then introduce the contrast:
Event-driven communication solves these problems by turning direct calls into facts broadcasted to the system.
The core idea behind EDA
Instead of saying:
“Hey Payment, do this now!”
EDA says:
“OrderPlaced happened.”
And walks away.
Whoever cares will react.
Here are some advantages of EDA. I am not going in to much details of it. But it can be self explanatory.
- Independent scaling
- Failure isolation
- Loose coupling
- Async processing
3. Let’s Try to understand some words/jargon used in EDA
Producer:
A Producer is a source system(application) which triggers an event to the specific topic. Producer doesn’t care who will consume event. Its role is just produce/trigger event and that’s it.
Event:
As we have seen starting of this article, that event represents a fact that something has happened in the business domain at a specific point in time. You can refer full definition at very beginning of this article.
Broker:
A broker is a is computer, instance or a container running the kafka process. A broker is a core of the messaging system. It role is
- manage partitions
- to reading events,
- writing the event to disk(logs),
- forward event to the specific topic
Consumer:
A consumer is a destination system(application) which receives an event from the broker on a specific topic. This is calling a consumer because it consumes the event(message)
4. Broker ( A core component of Messaging System)
As we see broker explanation in above paragraph, A broker is an instance in running kafka process. Basically it a core of a whole messaging system. Let’s take a minutes to understand broker functions in brief.
In Event Driven Architecture, the broker is the backbone of the system.
- Producers emit facts (events)
- The broker stores and distributes those facts
- Consumers react independently
The producer does not know:
- Who consumes the event
- How many consumers exist
- What actions they perform
Common Examples of Brokers
Popular messaging brokers include:
- Apache Kafka — high-throughput, log-based, event streaming
- RabbitMQ — message queues with routing and acknowledgments
- Amazon SQS
- Apache Pulsar
In the next section of this topic, we will learn more about Apache Kafka and some hands-on practical with producer consumer example with Java Spring Boot applications.
