Event-driven architecture is a system design pattern where services communicate by publishing and consuming events rather than direct database access, using Apache Kafka as a central event bus. In this architecture, services fire events once and forget them, while other services subscribe to topics to process these events independently. This approach eliminates database bottlenecks in microservices by decoupling services, enabling parallel processing, and allowing schema evolution without breaking consumers.
Deep Dive
Prerequisite Knowledge
- No data available.
Where to go next
- No data available.
Deep Dive
How Event-Driven Architecture Works?
Added:Hello everyone. In this particular video, we're going to whiteboard and understand what is event-driven architecture and how does a Kafka fit into this picture? Let us jump into the whiteboarding session.
So, the concept that we're going to understand today in this whiteboarding session is event-driven architecture.
Now, what do I mean by it? Let me explain it.
We have an app, let's say.
So, we have an app or we have a website.
These app and website are what we call as front-end, correct?
These are called as front-end.
Now, these would interact with some back-end tools.
These would interact with one or more back-end tools to get some results done.
When all of these operations finishes, they would write these data. They would write these data to database, for example. Fine?
And this design is a monolithic architecture. There is a single database here.
Once they write this data, there would be other services. They would be needing this data, so they would be consuming this information from the database, okay? So, they would be consuming this information from the database itself.
So, these could be fraud services that are there. These could be payment processing gateways that are there or ledger services, etc. For example, let's say you are building a shopping app. So, there's an app and there's a website.
When somebody places an order, first they place the order, the back-end interacts, the data goes to database, then there is a fraud service that runs and says if this order is a fraud or not, a payment reconciliation microservice that says if the payment is successful or not.
What is the bottleneck here?
If you observe properly, the key bottleneck here is the database.
And in fact, when you have multiple microservices, okay? So, when you're having other databases in the future, If you are having a microservice architecture, you might say this is not a single bottleneck, which is correct. But, imagine all of them needing to interact to get one single piece of information, which is now spread across so many places, which becomes impossible to really get things done. This is where the event-driven architecture comes in.
But, now you have a question. Where do I really put an event into? Should I put an event into a database? Not really.
We're going to replace this with one simple tool that is known as Apache Kafka. Let me actually erase only the pieces that can be replaced. So, now instead of a database, what we do is we replace the database with Let me clean this one also.
We replace the database with Apache Kafka.
Now, Apache Kafka does one thing simple.
Inside Apache Kafka, you can have multiple topics. Uh for the simplicity of it, so let's use a different color.
For the simplicity of it, let's say we have one topic here.
And this topic is called as orders.
Every company has orders, so we can go with this one simple example.
Now, what happens here? Observe carefully. Whenever there's an interaction here, an event gets fired here. What gets fired? An event.
Now, this event can be any format, but for simplicity's sake, we're going to take JSON as a format.
Now, this JSON format will have a lot of information. Let me try to write the information that might have.
It can have order ID.
It can have order ID.
It can have payment information. Okay?
It can have card information. What was the card that was used? It can have item information, the item that needs to be dispatched, and it can have date, for ex- All this information is required for one or the other microservice to function properly. What do you mean by this?
Observe. The order ID and payment information, the order ID and payment information, is taken by the fraud service to make sure the order is not fraud.
Then, we have the card information that goes and gets stored securely in the billing database so that the card information is not actually leak and nobody having access to this billing database. The item information here is sent out to the dispatching service.
Dispatching service to make sure the item is dispatched and the order gets delivered. Fine? So, this is separate service. And of course, the date is used by all of them. See how many services are using this? We have fraud, we have billing, we have dispatching. This is about the simplest example that you can think of. In fact, we'll have hundreds of such events coming from everywhere and Kafka now becomes a central nervous system for holding all of those events.
So, this architecture for a microservice is known as fire once and forget.
It is known as fire once and forget because the microservice is going to fire the event once and it doesn't have to worry about it.
Now, it just just forgets about these events completely. Every microservice that needs it, it subscribes to this event and just want to take this event and process further.
If this particular microservice, let's say the billing microservice or the fraud microservice, wants to add a new field here. So, we have order ID here, payment card, item, date. Let's say, apart from all of this, let's say there is also the user ID here. And the fraud service gets it.
It has to interact with the back-end service to make this enabled enabled in this particular schema.
That is called as schema evolution in Kafka.
Now, this central piece of architecture, Kafka itself, has a lot of things inside it.
That is Kafka topic, broker, producer.
In this case, these are the producers here.
These are the subscribers here. And how do failovers happen? How does Kafka scale? etc. But nonetheless, what we wanted to understand is what is an event-driven architecture. That's it.
That's all we wanted to understand. An event-driven architecture is a way in which my back-end services or the microservices can just fire an event to Kafka and forget about it. And every other service that wants to read it can simply subscribe to the events and process it.
That is what event-driven architecture is. I hope you understand this concept pretty well in this by putting this here. But do check out the event-driven architecture course on Kafka at cloudcode.com.
>> [music]
Related Videos

TOP 15 Data compression Interview Questions and Answers 2019 Part-2 | Data compression | Wisdom jobs
wisdomjobs
281 views•2019-06-28

CTS 158: 802.11w Management Frame Protection
ClearToSend
4K views•2019-02-04

NDSS 2019 Send Hardest Problems My Way: Probabilistic Path Prioritization for Hybrid Fuzzing
NDSSSymposium
496 views•2019-04-02

How realistic is Cities: Skylines?
CityBeautiful
159K views•2019-02-14

GUIs & TUIs: Choosing a User Interface for Your Python Project | Real Python Podcast
realpython
2K views•2025-04-04

The OSI Model - Explained by Example
hnasr
225K views•2019-05-12

Cloud Computing - Introduction
elithecomputerguy
98K views•2019-10-07

From Traveler's Dilemma to Dynamic Routing | Demystifying Networking
IITBombayJuly
5K views•2019-08-04
Trending

WOW! Judge TURNS THE TABLES on Trump in His OWN $10B LAWSUIT!!!
MeidasTouch
197K views•2026-07-23

Playstation NO DISC/NO BUY Fight Is Over...
DavidJaffeGames
4K views•2026-07-23

Steam and Xbox Just Dropped The Hammer On PlayStation
OhNoItsAlexx
9K views•2026-07-23

Americans Confused in Australia for 17 Minutes Straight
IWrocker
17K views•2026-07-23