Consistency Patterns + CAP Theorem
1. Consistency Patterns
1.1. Strong Consistency
After an update is made to the data, it will be immediately visible to any subsequent read operations. The data is replicated in a synchronous manner, ensuring that all copies of the data are updated at the same time.
It also means that the system is not highly available and has high latency.
Example: Financial system
When a user transfers money, all account balances are updated immediately across the system. Every user sees the same latest balance, preventing inconsistencies.
User A transfers $100
│
▼
+-------------------+
| Primary Database |
| Balance Updated |
+-------------------+
│ │ │
Sync │ │ │ Sync
▼ ▼ ▼
+------+ +------+ +------+
| DB 1 | | DB 2 | | DB 3 |
+------+ +------+ +------+
All reads return the same updated balance immediately.
1.2. Weak Consistency
After an update is made to the data, it is not guaranteed that any subsequent read operation will immediately reflect the changes made. The read may or may not see the recent write.
This can lead to inconsistencies and conflicts between different versions of the data, but it also allows for high availability and low latency.
Example: Multiplayer games
A player’s action may appear instantly to some players but not others due to lag or temporary connection issues. The game continues running even if some updates are missing.
Player A moves
│
▼
+----------------+
| Game Server |
+----------------+
│ │
Fast Slow/Lost
Update Update
▼ ▼
Player B Player C
Player B sees the move immediately.
Player C may see it later or miss it temporarily.
1.3. Eventual Consistency
Eventual consistency is a form of Weak Consistency. After an update is made to the data, it will be eventually visible to any subsequent read operations. The data is replicated in an asynchronous manner, ensuring that all copies of the data are eventually updated.
This means that the system is highly available and has low latency, but it also means that there may be inconsistencies and conflicts between different versions of the data.
Example: Social media platform
When a user posts content, some users may see the update immediately while others see it later as the data propagates across regions.
User posts a photo
│
▼
+-------------------+
| US Data Center |
| Post Visible |
+-------------------+
│
Async Replication
│
┌────┴────┐
▼ ▼
+------+ +------+
| EU | | Asia |
| DC | | DC |
+------+ +------+
Users in other regions may see the post a bit later.
2. CAP Theorem
According to CAP theorem, in a distributed system, you can only support two of the following guarantees:
Consistency - Every read receives the most recent write or an error
Availability - Every request receives a response, without guarantee that it contains the most recent version of the information
Partition Tolerance - The system continues to operate despite arbitrary partitioning due to network failures
Partition Tolerance
Network partitions are a specific type of failure — nodes stay alive but can no longer talk to each other. The network splits into isolated groups (partitions).
Example: if the cable between a Seoul DC and a Busan DC cuts out:
Seoul nodes work fine among themselves
Busan nodes work fine among themselves
But messages between Seoul ↔ Busan don't get through
So "Partition Tolerance" means: can the system keep operating even when the network splits like this? This is different from a node crash — the machines are up, the connection is just severed.
Networks aren't reliable, so you'll need to support partition tolerance. You'll need to make a software tradeoff between consistency and availability.
CP - consistency and partition tolerance
Waiting for a response from the partitioned node might result in a timeout error. CP is a good choice if your business needs require atomic reads and writes.
✅ Strong Consistency
AP - availability and partition tolerance
Responses return the most readily available version of the data available on any node, which might not be the latest. Writes might take some time to propagate when the partition is resolved.
✅ Eventual Consistency
