Read a Thin Book - Cloud Architecture Patterns - 5 - Eventual Consistency

CAP Theorem

It is impossible for a distributed computer system to simultaneously provide all three of the following guarantees:

Consistency: everyone gets same data
Availability: has ongoing access to system
Partition tolerance: system continues to operate despite failure of part of the system

Guaranteeing consistency is easy when data is on a single node, but once the data is
distributed, partition tolerance needs to be considered. What happens if our nodes can
not communicate with each other due to failure, or simply cannot do so fast enough to
meet our performance and scalability targets? Different tradeoffs are possible. One
popular choice for cloud-native applications is to favor partition tolerance and availability and give up the guarantee of immediate consistency.

Eventual Consistency

Choose between displaying stale data and scaling more efficiently.

Applications that do not guarantee immediate consistency are said to be eventually consistent.

eventual consistency can be a powerful feature that enables better scalability. Eventual consistency is not a deficiency or design flaw. When used appropriately, it is a feature.

New term but old idea.

Eventually consistent does not mean that the system doesn’t care about consistency. Most data is consistent virtually all of the time. There is just a business-tolerable delay before updates fully propagate. During this delay, different users may see different versions of the data.

Examples

ATM, check depositing, DNS etc


RDBMS vs NoSQL

RDBMS: ACID easy for single node

Atomicity: all completes or none
Consistency:
isolation: transactions competing to change same data are applied sequntially
Durability: committed data are not lost.

NoSQL: not only SQL

BASE:
Basically available: repond with even stale data
Soft state: state might not be consistent and might be corrected
eventually Consistent: allow for delay before any individual data change completely propogates though the system.

Usually designed to support easy sharding

configurable consistency is available if you want to trade of performance in some areas.

Misc

dealing with eventual consistency is simplified if all writes go to single location. this is adopted by couchbase and mongodb, which only accept write to master node, other nodes are read-only.