Это видео недоступно.
Сожалеем об этом.
Lesson 175 - Events vs Messages
HTML-код
- Опубликовано: 13 авг 2024
- In lesson 165 I spoke about event-driven architecture and when you should (and shouldn’t) use it. In this lesson I’ll take a deeper dive into EDA by discussing the differences between events and messages (yes, they are different things!). Then I’ll show when you might want to use messages within an event-driven architecture.
Reference Links:
Event-Driven Architecture: www.developertoarchitect.com/...
Software Architecture Monday: bit.ly/3dadEe3
Fundamentals of Software Architecture: amzn.to/3rgFLjY
Software Architecture: The Hard Parts: amzn.to/3BjMMF2
Amazing videos. I am not sure why your channel is underrated. I loved every single video. They are so simple, informative and easy to understand. Thanks and keep it up.
Glad you like them!
Very good explanation Mark! Thank you for your amazing lessons every week.
Thanks!
reminds me of being back in uni watching vids like these, but keep it up love ur vibe.
Thanks!
Clearly and succinctly explained with a practical example. Many thanks.
Don’t know if you have covered this concept. Would it be possible for you to cover sagas and share your opinion about how to implement a business transaction that spans multiple services?
That would be challenging to do in a 10 minute video because there are so many elements involved, but I will work on a way to introduce that in an upcoming video
Software is just reflection of thoughts processing. Thanks Mark❤
Thank you. One from the best episod :)
For me as front end developer it was hard to get the core differences between them. And now I understand. Thanks a lot!
any online courses or YT channels like this to learn front end development?
excellent. Many thanks
Very good lesson. Thank you
Glad you like it!
I think this is somewhat comparison of apples to oranges.
Event is an essense and message is just one of the communication forms.
We can have event with messaging for example through rabbitmq fanout exchange or kafka topic. It will not be directly addressed to any service.
We can have event without messaging for example they can be stored in a storage and all services or another parts of the application itself which are intersted in this event can read from a storage without any form of messaging being involved.
Great video, as usual. Thank you, Mark!
I think in real world scenario there could be another use case when you have to use messaging instead of firing an event. In exising enterprise infrastructure you may deal with legacy payment system that is unable or too expensive to subscribe to the events generated by your new shiny order management. It might be even a point where you do the synchronous call in your otherwise asynchronous system.
Ah yes, the ole "third party service" issue. Indeed, yet another possible use case!
Thanks for this video! While I am a big fan of the orchestration-based approach in Order Placement because the process is evident, easy to understand and not "hidden" by passed-around events, in this example Inventory could consume "payment applied" and Notification could either use "payment applied" or "inventory updated" to ensure the processing order.
I tend to agree as well. That said, i've had some really complex scenarios at some clients where even subscribing to events to manage the ordering of messages has led to confusion and unpredictability. Essentially it's nice to know there's an alternative in the blue messages for the guarantee 🙂
I've been working on things related to this, order and payment, and from a monolithic to distributed architecture. I've chosen to mix both. In my case, for better flow control, and to keep thing running, orchestration fits better most of the time. But I can use events for some things like notification for exemple.
Looks like messaging can bring an "order" to process however event can only be async.
Never thought of it that way.
One fallacy that I always see is that asynchronous events = loosely coupled. In your examples there is still semantic coupling which I typically address with the Canonical Data Model pattern (Woolf & Hohpe). Here I see the contract ownership moves from the publisher to the owner of the canonical topics/router.
You are so correct! Admittedly, services are more loosely coupled in EDA, but we tend to forget about the contract coupling. A change to a contract can breat services you don't even know about!
@@markrichards5014 Loving the series! It's a great refresher and rationale for things that we do without really thinking about the why. One complaint is that you're making it too clear - make sure you include more buzzwords to keep the architecture mystique, and general architecture smugness.
@@atkinpaul LOL!!
great,I like your way of explaining those things.
Great video, thank you! I think there's a typo where it should be message payload instead of event payload on the right in case of message in 3:51.
Wow, thanks for catching that error!
one thing tho, in my r70xs, im picked up some weird like low end thunks, may wanna use some eq to cut off that low end, prefereably prolly some mid/side eq, hi pass the sides @ 2-300hz. or just use RX 10 or something similar to clean the audio prolly. Or examine ur mic stand hehe, maybe getting a spider mount/shock mount basically to get rid of those thuds.
peace and love ;)
it kept FREAKING me out though i was like "ARE THE ROBOTS HERE?" lol
Thanks for the feedback, I'll check it out and see what's causing that. I don't use a keyboard, but i'll be more careful when pressing my ipad screen to see if that makes a difference in future lessons.
Although i really enjoyed the idea of listening the "payment applied" event by an order placement service. Thats a great idea!
I always try to leverage events first before relying on messages as well.
Bought your book.
Im a college student and love learning about architectures of data intensive applications.
Awesome! I hope the lessons help you!
Hello! Nice lesson, thanks! By the way is there any lesson about how to do request-response communication using messages? For example, if I use Kafka, do I need to create two topics: one for the request and one for the response? Thanks for the response!
Yes! Check out my very first lesson (Lesson 1) on my website at www.developertoarchitect.com/lessons/lesson1.html. Now this just covers messaging and does not include Kafka, but Kafka would like not be appropriate for request/reply messaging (you'll see why after looking at lesson 1)
I think that such rigid interactions that were shown in a blue color in form of direct commands should not be considered in first place when we have EDA. This looks like some sort of saga-pattern with that we have no separate coordinator service and instead order placement act like an occasional coordinator and mutualy depend on three other services. Next step will be some other service that acts essentialy the same and creates its own set of mutual interservice dependencies.
In the end there will be such a great count of mutual dependencies that we will loose the ability to shutdown any separate service and deploy or maintain them.
I tend to agree as well. That said, i've had some really complex scenarios at some clients where even subscribing to events to manage the ordering of messages has led to confusion and unpredictability. Essentially it's nice to know there's an alternative in the blue messages for the guarantee 🙂
Hi @Mark Richards Great Video as usual. So incase these dependencies need to be better sequenced, there might be more granular events ?? For example Order Booked event might trigger both payment and inventory updates but shipping will wait for "Payment Complete"?? Also can you create a video(s) on Event / Message design , best practices etc. or point to the best resource(s). Thanks.
That might be another way to manage sequencing and event ordering - one of the harder parts of EDA!
It seems Javascript asynchronous nature best suited for EDA. Java added the reactive module recently. But although I hate Javascript and Martin Fowler doesn't consider it a programming language. I see it is best suites EDA what do you think Mark?
EDA is an architectural style that can be implemented in a variety of languages, and yes, I agree with you that Javascript is certainly suitable for event-driven architecture.
The moment "apply payment" went blue, I felt like eventstorming began to emerge: blue stickynote tends to be followed by an orange one ("payment applied"). :)
Agreed. I try to avoid it, but was wanting to show a possible use of messages to better manage a required ordering of the process. Event ordering is always one of the hard parts of EDA!