26 thoughts on “Using sagas to maintain data consistency in a microservice architecture by Chris Richardson

  1. Can somebody explain to me why is it not a good idea to send msg inside a txn? if a msg was not transmitted then isnt it perfectly ok to rollback the transaction? Wont tailing the commit log of db get us the same behavior?

  2. I incorporated a company in 2007 who's goal was simply to proclaim the wonderfulness of MicroServices. Since (and before) then, I have never seen such a flawless talk related to MicroServices. Every other "concern" about distributed systems, Service-Oriented Architecture, Statelessness, Events, Administration, Security, and so forth have all been so mundane. And frankly, all of those other concerns can be mocked out in fairly generic frameworks. This talk touches on the actual MEAT of Software Development which is different for every customer and is the actual fun challenge. It may be stuff that experienced MicroService people know, but it has never been spoken so eloquently. I appreciate this talk very much.

  3. If only there was some way for a database to expose a consistent interface layer while still allowing the "private data" (ie, actual tables) to be modified "under the covers".

    Oh wait, there is. Views. Stored procedures. Functions.

    You do not need an application level API layer to provide data model independence. Views/procs/functions *are an API layer*.

  4. Started as a good talk, then slightly became messy after the 'theory of sagas' and when all problems were 'interesting' (but without solution), then, when it came to 'practical' part, everything turned into a complete mess with reinventing message brokers on top of specific features of databases. Anyway, we will probably get another 'open-source' framework 🙂

  5. Not sure I get it. How is this not just a distributed transaction where you've added the concept of compensating actions.

  6. Great talk. Learned a lot. Question, at 29:50, isn't it a bad idea to use choreography under any circumstance since it no longer loosely couples microservices (which is one of the main benefits of a microservices architecture)? I know he mentions the following centralized approach which is better. But what I'm curious about is, "shouldnt one avoid (at all costs) doing choreography and not even say that is a viable option in the first place?"

  7. Great talk! I hope Sagas don't manifest themselves as ServiceBus. Whereas Sagas are some state machine implementation, people would abuse them until it becomes another ball of mud. I would rather prefer microservices to be along the following lines:
    – Define your bounded context well so that they are relatively independent and will have consistent state within the context
    – If you must have other services decide a consistent state (those shouldn't be lot if you have followed the above), rely on synchronous calls to other services. With next generation protocols like gRPC performance impact is negligible
    – Leverage service mesh framework like Istio for coordination

  8. I'd only add some minute or two about idempotency in some key moments of the process. Despite of that, this is an excellent talk.

  9. Why not just have a separate "Transaction Service" that tracks the steps and whether they fail or not?

  10. CreateOrderSaga? Really?
    Reinventing distributed transaction manager under a new name. The only difference is the sequential rollback invocation. Some silly stuff.

  11. Great talk! NServiceBus has a pretty good implementation of this. https://docs.particular.net/nservicebus/sagas/

Leave a Reply

Your email address will not be published. Required fields are marked *