Consistency & Isolation in Distributed Systems

In distributed systems, consistency means how up-to-date a piece of data is across all nodes.

Consistency Levels#

Linearizable Consistency#

The strongest model. Every read reflects the result of the latest completed write — no matter which node served it.

write x = 13 → write x = 17 → read x → 17  ✅
write x = 1  → read x → 1                   ✅

Eventual Consistency#

The weakest model. Replicas may temporarily return stale data, but will converge to the latest value over time.

write x = 10 → read x → 5  (stale)
...time passes...
read x → 10  ✅ (eventually consistent)

Causal Consistency#

A middle ground. Causally related operations must be seen in the same order by all nodes. Unrelated operations can be seen in any order.

update x = 20 → read x (must see 20)  ✅
update y = 10  is independent → can execute in parallel

Quorum#

A configurable model. Reads/writes require acknowledgement from a majority of replicas.

Formula for strong consistency:

R + W > N

• R = min replicas to read from
• W = replicas to write to
• N = total replicas

If R + W ≤ N → eventually consistent.

Consistency Level Trade-offs#

Database Transactions#

A transaction is a collection of queries that form one unit of work. Transactions are atomic — either all queries execute or none do.

• BEGIN — marks the start
• COMMIT — persists all changes
• ROLLBACK — undoes all changes

Isolation Levels#

Isolation controls how transactions interact with each other when running concurrently.

Read Uncommitted#

Allows reading data that another transaction has written but not yet committed.

• Problem: Dirty reads — you read a value that gets rolled back.
• ✅ Fastest; minimal locking overhead
• ❌ No data accuracy guarantee

Example:

T1: write x = 10 → ROLLBACK
T2: read x → 10  ❌ (dirty read — this value never persisted)

Read Committed#

Only reads committed data. Eliminates dirty reads.

• ✅ Prevents dirty reads
• ❌ Non-repeatable reads — same row can return different values within a transaction if another transaction commits an update in between

Example: T2 reads x=10, T1 updates and commits x=20, T2 reads again and sees x=20 — two different values in the same transaction.

Repeatable Reads (Most Used)#

If you read a row once in a transaction, subsequent reads return the same value, even if another transaction commits updates.

• Uses row-level locks or MVCC (Multi-Version Concurrency Control)
• ✅ Prevents dirty reads and non-repeatable reads
• ❌ Still allows phantom reads (new rows inserted by another transaction appear)

Optimistic Concurrency Control: If two transactions try to update the same row, only one succeeds; the other rolls back.

Serializable#

The strongest isolation level. Transactions execute as if they were serial (one after another). No other transaction can interfere.

• Prevents phantom reads (uses predicate-based locking)
• Uses strict two-phase locking (S2PL) or timestamp-based ordering
• ✅ Prevents dirty reads, non-repeatable reads, and phantom reads
• ❌ Least efficient due to heavy locking

Summary#

Efficiency: Read Uncommitted > Read Committed > Repeatable Read > Serializable

Isolation: Read Uncommitted < Read Committed < Repeatable Read < Serializable