InfoQ Homepage Presentations Data Consistency in Microservice Using Sagas
Data Consistency in Microservice Using Sagas
49:23
Summary
Chris Richardson discusses messaging, durability, and reliability in microservice architectures leveraging the Saga Pattern. He shows how sagas work and how they differ from traditional transactions, and describes how to use sagas to develop business logic in a microservices application. He also describes the design of a saga framework for Java and shows a sample application.
Bio
Chris Richardson is a developer and architect. He is a Java Champion and the author of POJOs in Action, which describes how to build enterprise Java applications with frameworks such as Spring and Hibernate. He was also the founder of the original CloudFoundry.com, an early Java PaaS for Amazon EC2. He consults with organizations to improve how they develop and deploy applications.
About the conference
Software is changing the world. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.
Jan 31, 2018
Community comments
Great talk, thanks Chris!
by Vadim Samokhin,
perfect prensentation
by fangquan zhang,
Good book!
by Gabriel Kastenbaum,
Command as another Entity
by Dmitry Yegorov,
Great presentation, this is how exactly we implemented Order Management.
by Vaibhav Natu,
Data Consistency in Microservice Using Sagas
by Igor Rozenberg,
Great talk, thanks Chris!
by Vadim Samokhin,
Your message is awaiting moderation. Thank you for participating in the discussion.
The part on resisting the impact of isolation anomalies is probably the most insightful.
Talking about where to start with this great technique, I think there are several major points to be taken when designing a system with sagas.
First, service boundaries should be defined very carefully. Udi Dahan has a lot to say on this topic, here is an excerpt of his major perspectives.
Second is the consequence of the first point. Sagas, CQRS, etc should not be a higher level architectural pattern. SOA should. Events that sagas publish should tell only *what* happened, with almost no data. Typically, it's an id.
Talking about your orchestration vs choreography approach, personally I prefer choreography, since I treat my sagas as DDD aggregates. So it's just a natural choice for me. Here is an example of how the overall picture could look like.
And finally, here is how I deal with publishing messages problem you described, in a bit greater detail.
Thanks again for sharing this video.
perfect prensentation
by fangquan zhang,
Your message is awaiting moderation. Thank you for participating in the discussion.
perfect
Good book!
by Gabriel Kastenbaum,
Your message is awaiting moderation. Thank you for participating in the discussion.
I read a good part of "Microservices Patterns". It's a really good book!
Command as another Entity
by Dmitry Yegorov,
Your message is awaiting moderation. Thank you for participating in the discussion.
I don't see any particular reason why a Command cannot be represented as another entity in a Repository publishing events. Then the whole interaction within a Sage step can be minimized to interaction between repositories.
Great presentation, this is how exactly we implemented Order Management.
by Vaibhav Natu,
Your message is awaiting moderation. Thank you for participating in the discussion.
This is how exactly we had implemented Order Management system in 2014 using Saga, Events, Commands and Services. We used optimistic DB locking to make sure eventual consistency. But there was a subtle difference in implementation of the saga as we had only OrderSaga processing OrderCreatedEvent, OrderCompletedEvent etc.
Data Consistency in Microservice Using Sagas
by Igor Rozenberg,
Your message is awaiting moderation. Thank you for participating in the discussion.
If "ACID is so yesterday" why major NoSQL vendor MongoDB is working around the clock to introduce ACID transactions into version 4.0 of their product. It's a 100% nihilism to deny a 50+ years transaction processing theory and practice only because a particular database does not support it! Do not forget - today "bleeding edge of technology" is tomorrow LEGACY and Technical Debt!