[Avg. reading time: 13 minutes]

Terms to Know

Eventual Consistency

Eventual consistency is a model used in distributed systems, including some databases and storage systems. It allows for temporary inconsistencies between replicas of data across nodes, with the guarantee that all replicas will eventually converge to the same state.

Imagine a distributed database with three nodes (Node A, Node B, and Node C) that store a value for a particular key, “item_stock.” The initial value for “item_stock” is 10 on all nodes.

Node A: item_stock = 10
Node B: item_stock = 10
Node C: item_stock = 10

Now, a user wants to update the value of “item_stock” to 15. They send a write request to Node A, which updates its local value:

Node A: item_stock = 15
Node B: item_stock = 10
Node C: item_stock = 10

The system is inconsistent at this point, as different nodes have different values for “item_stock.” However, the eventual consistency model allows this temporary inconsistency. Over time, the update will propagate to the other nodes:

Node A: item_stock = 15
Node B: item_stock = 15
Node C: item_stock = 10

Eventually, all nodes will have the same value:

Node A: item_stock = 15
Node B: item_stock = 15
Node C: item_stock = 15

During the inconsistency, read requests to different nodes might return different results. Eventual consistency does not guarantee that all clients will immediately see the latest update. However, it does ensure that given enough time without further updates, all nodes will eventually have the same data.

Best Suited in Smart Home, Tracking Cars. Not great for Financial, Real-Time decision making.

Optimistic Concurrency

• Conflicts are rare
• Latency helps

Optimistic concurrency is a strategy used in databases and distributed systems to handle concurrent access to shared resources, like a dataset, without requiring locks. Instead of locking resources, optimistic concurrency relies on detecting conflicting changes made by multiple processes or users and resolving them when necessary.

| item_id| item_nm | stock  |
+--------+--------+--------+
| 1      | Apple  | 10     |
| 2      | Orange | 20     |
| 3      | Banana | 30     |
+--------+--------+--------+

Imagine two users, UserA and UserB, trying to update the apple stock simultaneously.

User A’s update:

UPDATE inventory SET stock = stock + 5 WHERE item_id = 1;

User B’s update:

UPDATE inventory SET stock = stock - 3 WHERE item_id = 1;

Using optimistic concurrency, both User A, and User B can execute their updates without waiting for the other to complete. However, after both updates are executed, the system checks for conflicts. If there were conflicts, the system would throw an exception, and one of the users would have to retry their transaction.

Suited for Smart Home Devices. Not suited on High-frequency multiple sensor writes.

Monotonic Reads

Once you read a value, you should never see an older value in the future — your view of data only moves forward in time.

Example: Meter Reading

Used to avoid inconsistent bill, GPS tracking and so on..

Last Write Wins (LWW)

Last Write Wins is a conflict resolution strategy used when multiple updates happen to the same data — the update with the latest timestamp wins.

Light is controlled by two apps at the same time. Whichever write has the newer timestamp “wins” and becomes the final state.

Alarm clock, set at 6:00am and manually you override it so later takes precedence.