eventual consistency and events

Sean Cribbs sean at basho.com
Mon Feb 28 17:55:56 EST 2011

This is handled in Dynamo-style architectures like Riak with quorums.  In Riak's case, you rely on the "W" and "DW" quorum values to determine what is an acceptable threshold for considering a write to be a success.  By default, W and DW are set to "quorum", which means N/2+1 (for N=3, this is 2) partitions must reply that they both 1) received the write (W) and 2) committed the write to durable storage (DW).  This allows you to lose one replica via outage, network partition, or overload and still have 2 copies available for read on the next operation.  An interesting side-effect of this is that even though a write may appear to have failed from the client's perspective, some partitions may have succeeded.

Sean Cribbs <sean at basho.com>
Developer Advocate
Basho Technologies, Inc.

On Feb 28, 2011, at 5:47 PM, Jon Brisbin wrote:

> In the midst of a discussion about messaging and eventual consistency and I'm wondering if there's a reasonable answer to the question:
> Is eventual consistency in a system that needs to know when it can start querying the system for the just-inserted data not a problem if there is an event triggered when this checkpoint is reached (like a publisher acknowledgement) that tells the client "remember that data you inserted a few cycles back? It's ready to be queried now" and takes the place of a transaction?
> The concern is that eventual consistency is bad when you need to know for sure that data was persisted to the store and the system currently uses transactions to ensure this.
> Thanks!
> Jon Brisbin
> http://jbrisbin.com
> Twitter: @j_brisbin
> _______________________________________________
> riak-users mailing list
> riak-users at lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

More information about the riak-users mailing list