HN Explorer

8 comments

[ 3.2 ms ] story [ 34.3 ms ] thread
preillyme
I'm really not sure where I stand regarding limited availability vs. eventual consistency. But, I do know that I like that Orly aims between these two extremes.
jason_at_orly
In strict CAP terms, eventual concurrency is a form of limited availability, but it's a special enough case that I think it deserves separate consideration.
seanmcdirmid
Another example using bank transfers that the banks would never tolerate themselves. Eventual consistency will be around for a long time to come.
jason_at_orly
Banking systems use limited availability rather than tolerate inconsistency. Banks are pessimistic.
seanmcdirmid
bullsh*t. Banks are the biggest users of eventual consistency out there, and have been since the 1500s.

See "Myth: Eric Brewer On Why Banks Are BASE Not ACID - Availability Is Revenue"

http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on...

jason_at_orly
True, but an ATM one thing, big transactions are different. And the high volume, highly available transactions are constrained to pools which are themselves handled with pessimism. You won't be able to walk away with a large wire transfer without the the money shifting thru locks.
mnasledov
This is presuming, of course, we don't care the Alice and Bob have different world views temporarily?
jason_at_orly
Differing views are a fact of life, but inconsistent views needn't be. But I think what you're asking is a question of how long a lag your app is willing to tolerate between Alice and Bob. Orly lets you set limits on that lag but never allows inconsistent reads, preferring to fail the operation if it can't be done within your app's constraints.