What's an Event Driven System?

Event Driven Systems pass and persist events. They have evolved from the publisher-subscriber model, and the design has some advantages. Events are immutable and can be replayed to allow the systems to take snapshots of their behavior. This allows services to 'self heal' as explained in the video.

A lot of transaction issues are alleviated once idempotency and retrial logic is added to a system. The system can retry messages an infinite number of times to the recipient till there is a message acceptance and acknowledgment from the receiver.

Event-driven systems are closely related to event sources and CQRS. Greg Young and Martin Fowler have been talking about these systems for a while. Events are persisted in something like a message queue, and hence the responsibility for retrial and persistence is moved to it.

These abstractions enable the programmer to focus on the business logic of a system and add subscribers to events with minimum coupling with other services. Decoupling the system is one of the advantages of event-driven systems.

One major disadvantage of this system is that it is difficult to reason about the flow of a request. Services can independently register for an event and consume it without the publisher being aware of it.

We talk about different applications using an event-driven architecture such as Git and Gaming Systems. We then discuss the advantages and disadvantages of such an architecture (Event Sourcing).

Code:

Looking to ace your next interview? Try this System Design video course! 🔥

00:00 Event-Driven Systems
01:17 Examples of EDA
03:42 Features
04:09 Advantages
04:19 Availability
06:14 Roll back
06:50 Replacements
07:30 Transactions
09:00 Drawbacks
12:32 When should you use it?
14:24 Real World Examples
14:40 Thank you!

References:

You can find me at:

[venkatkrishna]

One good thing about your videos is that you smile often, I feel that is much needed for the audience to be engaged through out your videos.

[Chorizzosoup]

Interviewer: what's the most important thing you want in your system design?
Me after watching this vid: You want headshots!

[zillionvolts]

You have mixed Event-Driven and Event-Sourcing!

[MaxPicAxe]

Wow your explanations are absolutely brilliant!

[sebastianwardana]

Its pretty cool of you to put this out! I might not pick up everything the first time, but its really elluminating and I really think about trying out new tech... thanks for that.

[saamtech]

I think this is more of event sourcing architecture (which is sub category of event driven) than event driven itself. In event driven architecture, my understanding is that there is no "replay" function nor there is implementation to support the replay functionality. A good example of it is almost all front end frameworks use event driven archs and they don't store any state

[pavithrae]

Thank you so much for the rich content.

[stiupidboy]

the title is soooo confusing!! The cover photo says "Event Sourcing" and the title says "Event Driven". I believe they are quite different things. Now you helped me mixed them up, thank you :)

[parvezmulla]

I never miss your system design videos! I always wait for ur next video on system design.

[MayankAggarwal]

Very interesting point you mentioned is that there is problem in understanding the flow of the code. I too faced myself this issue.

[vinayaka]

Hi Gaurav, can you please explain what is the difference between message queues and event driven system.

[anujvohra]

Thanks Gaurav. NIce video. May I also point out a few advantages of event driven architectures?
1. It is the only way in which you can implement SEDA and hence scale individual stages as load increases. As the EDA works in eventual consistency model, the scale up times are not as relevant (or as relevant as they may be in req/resp paradigm)
2. This is necessary if you are implementing a CQRS based system.
3. Lambda architecture is only supported with events (allowing us to arguably beat the CAPs theoren)
4. In container world, where a container can be evicted any time (in the middle of a transaction etc), we either need all services to be idempotent or have an event driven architecture in place. Idempotency is not always possible.
Regards

[learnandsharelive]

Hi Gaurav,
First of all, thank you so much for the content which you have highlighted on the "Event-Driver Architecture".


One of the disadvantages which you have highlighted was "unable to track the end-2-end flow" in this architecture. So to answer that we can use the "Orchestration" pattern and you might be aware. So, basically, design the "workflow-orchestration" as soon as you get the service response so that we'll come to know where it hangs in case of any failure. We're using "CAMUNDA" for the same.


Thanks!

[anildangol]

These videos are really good. More better, your excitement explaining things. There are lot of videos in youtube which may be better than your but man they are boring like hell that I get sleepy. Keep up the good work!

[souravkabiraj]

Great video.. nicely explained.. you are best youtuber of this genre..

[stormarrow]

I love your content! Thank you for sharing your videos!

[SuperEmilia]

You are too good with your explanation Gaurav.

[stoneshou]

The way you described persisting events in the service makes it sound like an append file rather than database

[phanikumar]

I believe why people like your video's is the way you enjoy the concepts and complete involve and explain them.. we can see in your eyes ( joy of happiness ) ... It could be great if you can show a video to community .. system design discussion with in group of people .. like everyone present their idea and how will you figure out the best in that room ...

[arithmeticerror]

Gaurav,

Multiple observations

1. You seemed to have confused event log with local db for each service. The micro service's local datastore *in general* is its materialized view, which is used to serve its requests, not to persist event log. There are message brokers which provide you with the event log directly with customizable retention polices (sure, you can use database as event log aswell, again whats the point of putting load on your DB which needs to serve requests when broker already stored this information previously and allows you to set retention policies which can be replayed later at any time?)

2. It is not true that migrating a message flow -> Request-response paradigm is hard. Its infact quiet easy as you are making simple RPC calls. Sure, you will not have the same resiliency guarantees as in messaging as we are moving to request-response paradigm

3. Its not true that event log is mandatory. You might want to keep it if the business requires it. Else, easiest option is to use broker as a task distributor & consume the messages