Compensations and the Saga Pattern

[Kelly Sommers]

Hiya,

 

I wrote a blog post a few weeks ago about the Saga Pattern and how it was designed to handle compensations in distributed systems.

http://kellabyte.com/2012/05/30/clarifying-the-saga-pattern/

 

Neil Conway pointed me to this paper from Pat Helland titled “Building on Quicksand”. Sections 5, 6, 7 and 8 cover material on compensations and found some quotes really great.

 

https://database.cs.wisc.edu/cidr/cidr2009/Paper_133.pdf

 

“In a loosely coupled world choosing some level of availability over consistency, it is best to think of all computing as memories, guesses, and apologies.”

 

“Consider the new ACID (or ACID2.0).  The letters stand for: Associative, Commutative, Idempotent, and Distributed”

 

I want to open a discussion about how these compensations are actually implemented. Pat Helland writes that each piece must be idempotent and that when the application is constrained to commutativity and associativity things get a lot easier than state being check pointed across failure units synchronously.

 

I have a lot of questions about how you author the distribution of workflow steps and their associated compensations. Pat mentions operation logging which I interpreted as the bits that make the workflow steps. Also, does this mean that the data model in the database must be modelled as a temporal table that stores deltas that get rolled up into current state (Event Sourcing) or are there other options? If I read the paper properly it sounds like if you are storing current state you have to go down the synchronous check pointing path that Pat tries to avoid.

 

Thoughts?

[Nate McCall]

I can't remember if it's in that paper or "life beyond distributed
transactions" (www.ics.uci.edu/~cs223/papers/cidr07p15.pdf - also by
Helland) but a key take away for me in figuring out how to build some
of this was understanding thresholds for the business' "apetite for
risk."

One of the examples he uses is ATM withdraws vs. large wire transfers.
The former being asynchronous and idempotent as the bank is willing to
risk a few hundred dollars to provide high availability. Whereas with
high-dollar wire transfers, you bet they are going through a whole
different work flow which will involve some locking.

Both papers have some awesome examples in them though. Thanks for
bringing these up.

> --
> You received this message because you are subscribed to the Google Groups
> "Distributed Systems" group.
> To post to this group, send email to distsys...@googlegroups.com.
> To unsubscribe from this group, send email to
> distsys-discu...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>