No video

Event Driven Architecture in the Real World! 4 Practical Examples

  Рет қаралды 31,248

CodeOpinion

CodeOpinion

Күн бұрын

Event Driven Architecture has many benefits. Loose and temporal coupling, scaling, resilience, and more. But what does that mean? What are some actual use-cases? I'm going to describe 4 practical examples of using event driven architecture.
🔗 Solace
solace.com/cod...
🔔 Subscribe: / @codeopinion
💥 Join this channel to get access to source code & demos!
/ @codeopinion
🔥 Don't have the JOIN button? Support me on Patreon!
/ codeopinion
📝 Blog: codeopinion.com
👋 Twitter: / codeopinion
✨ LinkedIn: / dcomartin
📧 Weekly Updates: mailchi.mp/63c...
0:00 Intro
0:39 External Integrations
3:20 Workflows
4:54 State Transfer
6:28 Temporal Decoupling
#eventdrivenarchitecture #softwarearchitecture #softwaredesign

Пікірлер: 33
@buildingphase9712
@buildingphase9712 2 жыл бұрын
Another amazing video, would also appreciate it if you would create a small end to end web api, ddd architecture project showcasing these concepts in an end to end project…
@dangersvns
@dangersvns Жыл бұрын
Amazing! meaningful video. Thank you for sharing!
@MollySpilberg
@MollySpilberg Жыл бұрын
Great video! It would also be great if you could add scenarios where EDA is not suitable, i.e. it's simpler and cheaper to make those HTTP/gRPC calls instead
@MohammadAhsan.ss.675
@MohammadAhsan.ss.675 7 ай бұрын
gRPC is synchronous and what I found through searching is its not suitable for loose coupling and also is synchronized while loose coupling is the motivation to use microservices. On the other hand, EDA is loose coupled and asynchronized.
@kolumbusbeatstv5773
@kolumbusbeatstv5773 Жыл бұрын
THIS IS LITERALLY THE BEST EDD Video I’ve seen ever
@CodeOpinion
@CodeOpinion Жыл бұрын
Well thanks!
@GC-qe8vc
@GC-qe8vc 16 сағат бұрын
To send an email you should use a mail server and not a service from Amazon. This whole idea that the ownership of the entire IT infrastructure of the world needs to pass to 3-4 megamonopolistic companies is madness, no matter how many euphimisms we create to describe it. Other than that, thank you for the video.
@dimitricharles9784
@dimitricharles9784 2 жыл бұрын
Great video, great introduction to this vast topic
@guava_dev
@guava_dev 2 жыл бұрын
2 videos in a week… 🎉
@juliaroberts9602
@juliaroberts9602 2 жыл бұрын
Very informative video! Some follow-up questions- 1) I am having trouble understanding the difference between #2 and #4. Are they not both trying to orchestrate an internal process? 2) i have been trying to figure out how granular the events need to be. We have a Human Resources system, where they are trying to support Enterprise events that span use cases #1. 3 where the goal is to notify downstream systems of data change. We are evaluating the granularity of the events - e.g. it could be New Hire or Promotion or Separation, or one could go granular e.g. new hire future, new hire retro, new hire onboarding. When the consumers get the events, they have to make a call back to get the change. Do we in such a case define the granularity of the events based on the use cases and consumer needs? I have come across event storming but for use case #1, we don’t need to have events for things that are not relevant for the use case e.g. say item added to wish list. Sorry for the long question! I have been trying to understand this but haven’t been able to find any resources. Any pointers would be greatly appreciated.
@CodeOpinion
@CodeOpinion 2 жыл бұрын
1) #2 is talking about workflows and orchestrating that, yes. However #4 was talking about how those orchestrations can be temporally decoupled so you aren't bound by time. 2) I have a few videos that talk about Event-Carried State Transfer (kzbin.info/www/bejne/p3ynY4yLia90jq8 and kzbin.info/www/bejne/f6uldpWciMxjq7s). Check those out and see if any of that helps. It really depends WHAT you're trying to do with events to determine what they should contain. If you have notification type events that are slim, often those are for workflow, and that's when you get into the callback situation. It's also important to know why other services need data.
@NervousNab
@NervousNab Жыл бұрын
Nice explanation. Do you have any book recommendation on EDA?
@zizliyev8367
@zizliyev8367 Жыл бұрын
Thanks for the video. The last part of it about temporal decoupling raised a question for me: What if we have a system where we have to fail after a while if one of the service is not responding. Since we are not waiting this service to do it's job, how we are going to know there is a failure? Setting a timeout for certain events to occur?
@CodeOpinion
@CodeOpinion Жыл бұрын
Yes, absolutely, that is one way. Check out this video, it will give you some ideas as you can use a time/expiry: kzbin.info/www/bejne/hovQYYWHfMimaZo
@zizliyev8367
@zizliyev8367 Жыл бұрын
@@CodeOpinion thank you for advice, i watched the video you suggested, it's really good. You have my respect :D
@mattgraves3709
@mattgraves3709 2 жыл бұрын
Which way do you want those events to flow typically?
@midoevil7
@midoevil7 2 жыл бұрын
Great video! But I was wondering if event-driven fits most of the cases in the late life-time of a project? I think there's a complication overhead with adding a broker and using event-choreography instead of having the whole work-flow in one place. From your experience you think it is worth it to start from the beginning with an event-driven architecture? or start with something simpler like service architecture and refactor later if things started getting complicated ?
@CodeOpinion
@CodeOpinion 2 жыл бұрын
This is a really good topic idea. EDA is great for established codebases. It allows you to build out more functionality that's decoupled from what you already have.
@chrismoutray9206
@chrismoutray9206 2 жыл бұрын
Do you have any views on syncing 'from' an external system? That is, pulling in a list of products on a regular, scheduled job? Btw great content from your channel!
@CodeOpinion
@CodeOpinion 2 жыл бұрын
Meaning another system is pulling data as a scheduled job? If so, nothing fancy other than if the amount of data it has to pull is very large. In that case it can be beneficial to have the initial request kick off it's own internal job or fan out the work into multiple smaller units. Giving the client back not the immediate response from the request, but an identifier or callback to provide it with the data once the request was processed.
@digitalcookworld3720
@digitalcookworld3720 Жыл бұрын
What would happen if the Event Broker is unavailable?
@CodeOpinion
@CodeOpinion Жыл бұрын
For publishing, use an outbox or a fallback (kzbin.info/www/bejne/qpTIgZWll52lqLs). For consumers, well they just consume when the broker is available.
@digitalcookworld3720
@digitalcookworld3720 Жыл бұрын
Thank you. Was quite helpful.
@MrAyuub22
@MrAyuub22 2 жыл бұрын
When would you use queues over topics, seems like in my company we always have one queue per consumer and just publish messages there
@MrAyuub22
@MrAyuub22 2 жыл бұрын
In the warehouse example, we would have a queue - statemachine - warehouse -billing
@CodeOpinion
@CodeOpinion 2 жыл бұрын
Queues for Commands, Topics for Events
@QuantQuest
@QuantQuest 2 жыл бұрын
Regarding temporal decoupling example, in NodeJs we can call warehouse and billing related methods asynchronously ( may catch them in their respective catch methods ). So, I believe that's correct and we may not need decoupling if we write code like that. Please comment. I do know you are explaining it from event driven architecture perspective but Node.Js is event driven, although we don't save those event like the kafka does. PS: I like the way you explain things by code and example.
@CodeOpinion
@CodeOpinion 2 жыл бұрын
They are two different things. Async programming models that are in-process are different than using durable queues to pass messages between processes, which is what I'm explaining in the video. I'm going to create another video to explain the differences.
@MJ46.91
@MJ46.91 2 жыл бұрын
how is this video dated 11 MAy 2022 and today is May 8th???
@CodeOpinion
@CodeOpinion 2 жыл бұрын
Huh?
@mabdullahsari
@mabdullahsari 2 жыл бұрын
I like to categorize events in 3 different "archetypes": - Domain events - RESTful events - Signal events
@mohammedjishad7062
@mohammedjishad7062 2 жыл бұрын
Please elaborate
Commands & Events: What's the difference?
9:18
CodeOpinion
Рет қаралды 10 М.
Кадр сыртындағы қызықтар | Келінжан
00:16
A teacher captured the cutest moment at the nursery #shorts
00:33
Fabiosa Stories
Рет қаралды 63 МЛН
👨‍🔧📐
00:43
Kan Andrey
Рет қаралды 10 МЛН
Пройди игру и получи 5 чупа-чупсов (2024)
00:49
Екатерина Ковалева
Рет қаралды 2,4 МЛН
Domain Driven Design: What You Need To Know
8:42
Alex Hyett
Рет қаралды 114 М.
Microservices with Databases can be challenging...
20:52
Software Developer Diaries
Рет қаралды 24 М.
Event-Driven Architecture (EDA) vs Request/Response (RR)
12:00
Confluent
Рет қаралды 134 М.
A Beginner's Guide to Event-Driven Architecture
37:28
Software Developer Diaries
Рет қаралды 9 М.
Vertical Slice Architecture, not Layers!
46:24
CodeOpinion
Рет қаралды 118 М.
Event Driven Architecture EXPLAINED in 15 Minutes
14:55
Continuous Delivery
Рет қаралды 28 М.
Beware! Anti-patterns in Event-Driven Architecture
10:34
CodeOpinion
Рет қаралды 14 М.
Event Driven Architectures vs Workflows (with AWS Services!)
15:49
Be A Better Dev
Рет қаралды 90 М.
Кадр сыртындағы қызықтар | Келінжан
00:16