Consistency Models

Introduction

In the realm of distributed systems, ensuring data consistency across multiple nodes is a critical challenge. Different consistency models are employed to balance between availability, partition tolerance, and consistency. This tutorial will explore various consistency models, their characteristics, and practical implications in distributed systems.

Concept

Consistency models define how updates to data are propagated and reflected across different nodes in a distributed system. The CAP theorem states that it is impossible for a distributed system to simultaneously provide more than two out of the following three guarantees:

1. Consistency: All nodes see the same data at the same time.
2. Availability: Every request receives a response, even if it's not the most recent version.
3. Partition Tolerance: The system continues to operate despite arbitrary message loss or failure of some nodes.

In this section, we will delve into different consistency models that aim to provide varying levels of these guarantees.

Strong Consistency

Strong consistency ensures that all nodes in a distributed system see the same data at the same time. This is typically achieved through mechanisms like two-phase commits (2PC) or Paxos. However, strong consistency often comes at the cost of reduced availability and partition tolerance.

Example:

Consider a simple key-value store with two nodes:

• Node A: key1 = value1
• Node B: key1 = value1

If Node A updates key1 to value2, strong consistency requires Node B to also update key1 to value2 immediately. This can be achieved using a 2PC protocol:

{
  // Node A initiates the transaction
  initiateTransaction();

  // Node A updates its local state
  updateLocalState('key1', 'value2');

  // Node A sends a prepare message to Node B
  sendPrepareMessageToNodeB();

  // Node B acknowledges receipt of the prepare message
  acknowledgePrepareMessageFromNodeA();

  // Node A commits the transaction
  commitTransaction();

  // Node A sends a commit message to Node B
  sendCommitMessageToNodeB();

  // Node B updates its local state
  updateLocalState('key1', 'value2');
}

**Output:**

```OutputBlock
{
  // Both nodes now have the same state:
  // Node A: key1 = value2
  // Node B: key1 = value2
}

Eventual Consistency

Eventual consistency allows for some delay in data propagation, ensuring that all updates will eventually be reflected across all nodes. This model typically provides high availability and partition tolerance but sacrifices strong consistency guarantees.

Example:

Consider a distributed database with two nodes:

• Node A: key1 = value1
• Node B: key1 = value1

If Node A updates key1 to value2, eventual consistency allows Node B to eventually update its state without immediate synchronization:

{
  // Node A initiates the transaction
  initiateTransaction();

  // Node A updates its local state
  updateLocalState('key1', 'value2');

  // Node A sends an update message to Node B (potentially delayed)
  sendUpdateMessageToNodeB();

  // Node B eventually receives and applies the update
  applyUpdateFromNodeA();
}

Output:

{
  // After some time, both nodes have the same state:
  // Node A: key1 = value2
  // Node B: key1 = value2
}

Session Consistency

Session consistency provides a session-level guarantee that all operations within a single client session are consistent. This means that operations within a session will see a linearizable order of updates, but different sessions may not.

Example:

Consider a web application with two nodes:

• Node A: user1 = { name: 'Alice', age: 30 }
• Node B: user1 = { name: 'Alice', age: 30 }

If a client session updates user1's age to 31, session consistency ensures that all subsequent operations within the same session will see this update:

{
  // Client initiates a session with Node A
  initiateSessionWithNodeA();

  // Client updates user1's age to 31
  updateUserAge('user1', 31);

  // Subsequent operations in the session see the updated state
  getUserAge('user1'); // Returns 31
}

Output:

{
  // Within the same session:
  // getUserAge('user1') returns 31
}