BT

InfoQ Homepage Presentations Data Consistency in Microservice Using Sagas

The next QCon is in London, Mar 4 - 6, 2019. Save an extra £75.00 with INFOQ75!

Data Consistency in Microservice Using Sagas

Bookmarks

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.

Recorded at:

Jan 31, 2018

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • 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!

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.