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.
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.
Another example using bank transfers that the banks would never tolerate themselves. Eventual consistency will be around for a long time to come.
Banking systems use limited availability rather than tolerate inconsistency. Banks are pessimistic.
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"
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.
This is presuming, of course, we don't care the Alice and Bob have different world views temporarily?
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.