

Eventual Concurrency vs. Eventual Consistency - preillyme
http://orlyatomics.com/2014/07/eventual-concurrency-vs-eventual-consistency/

======
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...](http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on-why-banks-
are-base-not-acid-availability.html)

~~~
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.

