A Beginner's Guide to Event-Driven Architecture

In this gentle introduction to Event-Driven Architecture, we will explore real-world use cases and main concepts such as Event Notification, CQRS, Event Sourcing, etc. We'll discuss common technologies and patterns, such as Messaging with RabbitMQ and Streaming with Kafka.
☕ Buy me a coffee: www.buymeacoffee.com/software...
🙌 Become my Patreon and get exclusive perks: / softdevdiaries
💼 Follow me on LinkedIn and drop me a message if you'd like: / gadirovgs
💻 Also, let's connect on GitHub: github.com/gusgad
📚 Resources:
blog.theodo.com/2019/08/event...
Event Notification and Event-Carried State Transfer patterns: / event-notification-vs-...
Event Sourcing: / event-sourcing-pattern...
CQRS: / event-sourcing-and-cqrs
Pub/Sub Pattern: ably.com/blog/pub-sub-pattern...
RabbitMQ tutorial: www.rabbitmq.com/tutorials/tu...
PostgreSQL Materialized Views: www.postgresql.org/docs/curre...
🕒 Timestamps:
0:00 Overview
4:57 Use cases
7:24 Event Notification pattern
17:49 Event-Carried State Transfer
22:32 Event Sourcing
27:44 CQRS
And don't forget to subscribe for more videos like this 😊

[@whoami2743]

This is the first time I learned about the basic of Event driven and Event sourcing

[@jackfilleyreviews6844]

Hey, love this content. Please keep it up!

[@raphauy]

Thank you!

[@TannerBarcelos]

Awesome video. Your content is teaching me a ton, and it all makes sense when I listen to your content over some others here on YT.
I did have a question
In the payment processing example, when the client is making the request to make an order, if the payment service succeeds and therefore the order service can update the orders for the user, wouldn't the user simply be moved on to the success screen irregardless of what happens down stream (inventory service update, email service etc.) ?
I would assume from the clients perspective, they should not be at the mercy of the rest of the systems processing and should only care about if the payment was processed and their money was taken out or not.

[@SoftwareDeveloperDiaries]

Thanks a lot! And yes, that's totally true. As long as the payment succeeds, the user can be forwarded to the success screen. My diagram should've reflected that 🙂

[@abhilashkr1175]

Thanks for the video. This is all theory but pls implement it

[@SoftwareDeveloperDiaries]

Will do in one of the next videos 🤙

[@AmarMishra]

Great work....can you please cover. RabbitMq in a separate video. May be conceptualize it as a class object . So that we can have publisher and consumer as 2 member methods of the same instance of rabbitmq client.
Was wondering if we can have a separate worker thread for consuming the event.

[@SoftwareDeveloperDiaries]

I'll cover that in a separate video soon!

[@alienmars2442]

I wonder if InventoryService processes fails, but EmailService sends email successfully, how should we gonna do ?

[@user-dh8rm3ob4f]

RABBITMQ deep dive please

[@user-so7vz3is9t]

Anyone has an idea on how to handle duplicates in an async context ?

[@Aleks-fp1kq]

1. 10:00 How can order-service forget about purchase when it is possible that while the payment was processed the product's balance dropped to 0 (zero)?
2. how to handle the case when inventory-service processes the event but fails to send the ACK message?
3. does the broker has to ACK back the ACK message? If yes, what if inventory-service fails to receive it?
4. event sourcing doesn't cause eventual consistency, but event driven architecture.
5. so how CQRS helps with the two DBs?
6. in reality our systems are hybrid depending on the communication scenario. as in, some services may opt for messages, some for sync communication.

[@SoftwareDeveloperDiaries]

Thanks for your questions, I will try to answer them 🙂
1. If the payment fails, no event will be emitted. But once it is emitted, the service forgets it. That's what was meant by "forgetting".
2. You have multiple strategies depending on your use case and needs:
a. Retry Mechanism: Implement a retry mechanism in your microservice. If the database operation fails, the service can try again after a certain period.
b. Dead Letter Queue: If the error persists after several retries, you can send the message to a Dead Letter Queue (DLQ). The DLQ stores messages that could not be processed successfully. You can later analyze these messages and decide how to handle them.
c.Event Sourcing: If a failure occurs, you can replay the events to bring your application back to a consistent state.
d. Compensating Transactions: If your operation has side effects, you might need to execute a compensating transaction to undo the changes in case of failures.
3. No, the broker doesn't have to ACK back. It's more of a "fire and forget" pattern, meaning the event publisher usually doesn't wait for an ACK.
4. Agree :)
5. It doesn't.
6. Exactly.

[@sauravkumarsharma6812]

Thanks for such a good knowledge make some practical or reference some git repo

[@dikatok]

I don't think event sourcing and cqrs have anything to do with EDA at all, they are individual patterns that can be used without any of the other patterns

[@SoftwareDeveloperDiaries]

Indeed, they are individual patterns. But EDA often relies on those :)

[@prashlovessamosa]

Can you please implement all that stuff it would be too helpful

[@SoftwareDeveloperDiaries]

I can! Just stay tuned 😊

[@prashlovessamosa]

@@SoftwareDeveloperDiaries great will wait for it.

[@emperoralthaf6264]

​@@SoftwareDeveloperDiariesHey that's awesome brother 🔥. Would like to see a payment integration using event driven architecture ❤.