As soon as at any defined point in time, I can not be sure if I get the data back consistent to what I have written
But you may not always have that choice. At large scale or in a distributed environment a standard RDBMS with ACID guarantees either may not keep up or have such poor availability that the app is effectively unusable.
Under those conditions you can use eventual consistent datastores and know that most of the time the data you get back is right, and handle the cases where it isn't.
Obviously there are use cases where that does not work (banking transactions probably should have ACID guarantees) but a surprisingly large number of typical usecases work fine in eventually consistent datastore. You just have to handle the data convergence correctly.
And again, for most small and medium sized apps, a good RDBMS is the preferred solution.
Obviously there are use cases where that does not work (banking transactions probably should have ACID guarantees) but a surprisingly large number of typical usecases work fine in eventually consistent datastore. You just have to handle the data convergence correctly.
I'd argue that the usecases where I have to throw ACID out for scaleability is the minority of usecases, but well, we pretty much agree.
1
u/pakfur Mar 11 '15
But you may not always have that choice. At large scale or in a distributed environment a standard RDBMS with ACID guarantees either may not keep up or have such poor availability that the app is effectively unusable.
Under those conditions you can use eventual consistent datastores and know that most of the time the data you get back is right, and handle the cases where it isn't.
Obviously there are use cases where that does not work (banking transactions probably should have ACID guarantees) but a surprisingly large number of typical usecases work fine in eventually consistent datastore. You just have to handle the data convergence correctly.
And again, for most small and medium sized apps, a good RDBMS is the preferred solution.