Solving distributed data problems in a microservice architecture | Microservices.io
Вставка
- Опубліковано 14 тра 2024
- To deliver a large complex application rapidly, frequently and reliably, you often must use the microservice architecture. The microservice architecture is an architectural style that structures the application as a collection of loosely coupled services.
One challenge with using microservices is that in order to be loosely coupled each service has its own private database. As a result, implementing transactions and queries that span services is no longer straightforward.
In this EDA Summit presentation, you will learn how event-driven microservices address this challenge. Chris Richardson, creator of microservices.io, describes how to use sagas, which is an asynchronous messaging-based pattern, to implement transactions that span services.
You will learn how to implement queries that span services using the CQRS pattern, which maintain easily queryable replicas using events. - Наука та технологія
this is goldmine
Learning from design guru is always a pleasure, thank you so much
I loved it. This presentations puts all components of a mature microservice together. I was looking for something like that for a long time. Congrats.
This was the best. You tackled most of the real-world problems in micro-services architecture.
Many Thanks.
Awesome presentation, loved that.
Thanks for all your efforts.
Thank you so much for sharing all this excellent info about distributed data problems in microservice architecture!!!! It is so appreciated!!!
Very nicely explained, every thing is crystal clear
Very good one & this is the best I have seen for micro-services.Thank you
Awesome general lecture on data composition and sharing in microservices from and industry leader.
Amazing content. I can't thank you enough!
Very clear as usual Chris :)
I love this deeply insightful video
I learned so much. Thanks!
Thank you!
it's awesome
ITS CALLED THE INSIDE STORY I LIKED IT
Great video, many likes. But CQRS, hmm one of the best architectural design patterns, but replicating databases for segregating commands and queries can get complicated and needs governance to ensure everyone follows the pattern, same applies for many other patterns of course.
gg, Chris!
The main problem I see with micro services is that it is overkill for an awful lot of systems. Sure if you are building a web based service and are expecting a few billion requests a day or more micro services are a must. But if you are building a hotel reservation system for instance you are maybe going to see a few thousand requests an hour if that. Looking at all the hoops one needs to jump through to make micros services a viable solution I am pretty certain that it will be way to heavy a lift for that hotel reservation system.
Unfortunately the cool new thing in software architecture being the best solution for everything seems to still plague many software architects thinking. Yes, micro services are a cool but complex solution it certainly has a place but that place is not in a simple solution that just needs to handle a few hundred interactions a minute.
Software architecture is just like any profession all about picking the right tool for the job, a monolith or a distributed monolith might be perfectly fine for the thing you have been tasked to architect. Sure it is not as sexy as the new kid on the block but it will provide enough resiliency and a far lower TOC than the new thing ever could.
Ok rant over 🙂
I love the presentation though it covers a lot of the micro service pitfalls many organizations are encountering when they dive into the wonderful world of micro services.
There are other benefits to microservices other than ability to handle web scale, if you have multiple teams it makes a lot of sense for them to work on self contained de-coupled services so you can get proper autonomy and ownership at the team level.
It really does depend on the use case and team set-up though, for example if I was designing an architecture for a startup where the team is small and they want to iterate fast I would probably go with a stateless monolith for simplicity and speed until such time as they prove the MVP and expand the team or the traffic/complexity tells you microservices are required.
Ultimately I think software engineering is still so young as a profession we need to be way more scientific and make decisions on the basis of data and measure rather than the opinion of the dominant alpha geek