6 ms·
Eventual Concurrency vs. Eventual Consistency
- preillyme 12y agoI'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 12y agoIn 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 12y agoAnother 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 12y agoBanking systems use limited availability rather than tolerate inconsistency. Banks are pessimistic.
- seanmcdirmid 12y agobullsh*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-why-banks-are-base-not-acid-availability.html http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on...
- jason_at_orly 12y agoTrue, 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 12y agoThis is presuming, of course, we don't care the Alice and Bob have different world views temporarily?
- jason_at_orly 12y agoDiffering 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.