Less strict locking to support more simultaneous access. In optimistic concurrency, multi users are able to perform actions on the same resources without locking each other, for example, one user can write without locking another user that’s reading the same resource. Some actions will still lock the resource exclusively, for example, a schema changes.
Is the opposite, a stricter locking is used. When a user is performing an action that requires lock, other users won’t be able to do anything that would conflict with the lock, until the lock is release from the owner (first user).
Eventual consistency guarantees more of availability than consistent data. This is achieved by prioritize availability (not locking the resource) rather than replicating the data.
The opposite of eventual consistency where it’s prioritizing consistent data across the system rather than availability.
Eventual consistency is classified as BASE (Basically Available, Soft state, Eventual consistency) semantics, as oppose to ACID principle.
Eventual / strong consistency is similar to optimistic / pessimistic concurrency. The difference is the terms eventual / strong consistency is often used in a distributed system where optimistic / pessimistic concurrency is used more in lower level, single entity such as database.
Azure Cosmos DB consistency levels, strong to weakest consistency:
– Strong consistency
– Bounded staleness
– Consistent prefix
– Eventual consistency