The CAP theorem states that it is impossible for a distributed computer system to simultaneously provide consistency, availability, and partition tolerance. You must give up one of these properties. Most systems choose to sacrifice consistency (eventual consistency), making them either AP (available during partition) or CP (consistent during partition). With AP systems like MongoDB, updates will propagate between nodes eventually, so clients may see inconsistent or stale data temporarily. CP systems guarantee consistency during a partition by blocking writes.

1. cap

2. cap theorem
• Eric Brewer (ex-Inktomi)
• Proved by Lynch and Gilbert

3. cap theorem
It is impossible in the asynchrounous network
model to implement a read/write object
that garantuees the following properties:
- Availability
- Atomic consistency in fair transactions
Or: If the network is broken,
your database won’t work

4. AP vs CP
• Real choices are
• Available - Partition
• Consistent - Partion

5. AP
• Multiple Nodes participate in writes
• System will be Eventually Consistent
• Storage System guarantees if there are no
new updates, all reads will eventually
return the same, last updated value
Examples:
- DNS
- ASync replication
- MongoDB with Slave-OK
- Memcache

6. eventual consistency
Master
Slave Slave
Client Client
Asuming update 1,2,3,4,5
Client will expect 1,2,2,2,3,4,5,5,5

7. eventual consistency
Master
Slave Slave
Client Client
However, we could get this: 1,2,2,4,2,5

8. eventual consistency
• Monotonic read consistency
• Pin client to certain slave / app server
• Failover still fails

9. multi master
Dynamo model
R - number of servers to read from
W - number of servers to get response from
N - Replication Factor
R + W > N has nice properties

10. multi master
Example 1 Example 2
R + W <= N R +W > N
R=1 R=2 R =1
W=1 W=1 W=2
N=5 N=2 N=2
Possibly Stale Data ‘Consistent’ Data
Higher Availability

11. R +W > N
If R + W > N you can’t both
have fast local reads and writes

12. network partitions

13. trivial network
partition

14. network write
possibilities
• deny all writes
• read fully consistent data
• allow writes on one side
• allow reads on other side (stale)
• allow writes on both sides
• give up consistency

15. multiple writer strategies
• Last one wins
• vector clocks
• Insert
• insert often means:
• if (!exist(x)) set(x)
• exist is hard to implement in eventually
consistent systems

16. delete
op1: set joe, age 40
op2: delete joe
op3: set joe, 41
- consider switching 2 and 3
- tombstone: remember delete and apply last op
wins

17. multiple writer strategies
• programmatic merge
• store ops instead of state
• replay operations
• did I get the last one ?
• Commutative operations
• conflict free
• anything that’s foldable

18. CP
• Sometimes we need global state
• Unique - constraints
• User registration
• ACL changes

19. Finally
uptime(CP + average developer)
>=
uptime(AP + average developer)
Where uptime is the system is up and non-buggy