Eventual Consistency in Distributed Systems | Learn System Design

Eventual Consistency is a consistency model used in distributed systems where all replicas of data eventually become consistent if no new updates occur. It allows temporary differences between replicas, improving system availability and performance.

• Replicas can continue serving requests even if updates have not yet propagated to all nodes.
• Given enough time without new updates, all replicas will synchronize and contain the same data.

Example: In a social media application, a newly posted comment may appear immediately for some users while others see it a few seconds later. After synchronization completes, all users see the same updated comment across all servers.

Characteristics

The characteristics of eventual consistency include:

• Asynchronous Updates: Updates are not immediately propagated to all nodes in the system. Instead, they are distributed asynchronously, which can temporarily cause different nodes to have different versions of the data.
• Lack of Strong Consistency Guarantees: Eventual consistency does not guarantee when all replicas will become consistent. It only ensures that if no new updates occur, all nodes will eventually converge to the same state.
• Delayed Propagation: Data updates may take time to reach all replicas across the distributed system. During this delay, users accessing different nodes may observe different values of the same data.
• Conflict Resolution: When multiple nodes update the same data simultaneously, conflicts can occur. Eventual consistency relies on conflict resolution mechanisms to reconcile these updates and achieve a consistent final state.
• High Availability: The system remains operational even during network failures or temporary partitions. Users can continue to read and write data while the system works to synchronize updates in the background.

Importance of Data Consistency

Data consistency ensures that all users and systems access accurate, reliable, and up-to-date information across a distributed system.

• Prevents errors and conflicts caused by different versions of the same data.
• Ensures business processes and applications operate correctly using reliable information.
• Improves user trust by providing a predictable and consistent experience.
• Supports accurate decision-making based on synchronized data.

Real-Life Example

Consider an online shopping application where a user adds an item to their shopping cart. Since the cart data is stored across multiple servers, the update may not appear immediately on every server.

For a short period, the item may be visible on one page but not on another because some servers have not yet received the latest update. However, as the update propagates through the system, all servers eventually synchronize and display the same cart information.

Note: Eventual consistency is commonly used in systems that prioritize high availability and partition tolerance over immediate consistency, such as social media platforms, shopping carts, and content delivery systems.

Working

Eventual consistency allows data updates to propagate gradually across replicas while ensuring they eventually reach the same state.

• Write Request: A client sends a write request to one replica (server node). The replica accepts and processes the update.
• Local Update: The receiving replica immediately stores the updated data locally. This allows local read requests to access the latest value without waiting for synchronization.
• Replication: The update is propagated asynchronously to other replicas in the system. Common replication methods include message queues, replication protocols, and gossip protocols.
• Inconsistency Window: During replication, different replicas may temporarily contain different versions of the data. The duration of this inconsistency depends on factors such as network latency, replication frequency, and system workload.
• Convergence: Over time, all replicas receive and apply the update. Once synchronization is complete, every replica contains the same data, achieving eventual consistency.

Use-Cases of Eventual Consistency

The usecases of Eventual Consistency are:

• Social Media Platforms: Social media applications prioritize fast updates and responsiveness. Temporary inconsistencies in likes, comments, or follower counts are acceptable as the data eventually synchronizes across all servers.
• E-Commerce Websites: Online stores use eventual consistency to maintain high performance and availability. Product inventory updates may take a short time to propagate, but all replicas eventually reflect the correct stock levels.
• Content Delivery Networks (CDNs): CDNs distribute cached content across servers worldwide. Eventual consistency allows content updates to propagate gradually while ensuring fast content delivery to users.
• Big Data Analytics: Large-scale analytics systems process massive datasets across distributed nodes. Eventual consistency enables efficient data processing while allowing updates to synchronize over time.
• Email Delivery Systems: Email services prioritize fast message delivery over immediate status synchronization. Delivery and status information eventually propagates across all related systems.
• Stock Market Data: Financial data platforms often tolerate small delays in data synchronization. While updates may not appear instantly everywhere, the system eventually reflects accurate market information.
• Online Gaming: Multiplayer games prioritize smooth gameplay and low latency. Temporary differences in game state may occur, but the system eventually synchronizes all players to a consistent state.

Differences between Eventual Consistency and Strong Consistency

The differences between Eventual and Strong Consistency are:

Implementation of Eventual Consistency

Imagine you have a system where you want to store some information (like names and ages) but this system is split across many computers (nodes) to handle a lot of users. Each node has a copy of this information, and they need to stay in sync (consistent) with each other.

With eventual consistency, we're okay with the information being slightly different on each node for a short time, as long as eventually (after some time), they all have the same correct information.

The code of Eventual Consistency

#include <iostream>
#include <unordered_map>
#include <vector>
#include <thread>
#include <mutex>
#include <chrono>

using namespace std;

// Define a simple key-value store
unordered_map<string, string> kvStore;

// Mutex for thread safety
mutex mtx;

// Function to update a key-value pair
void updateKV(const string& key, const string& value) {
    // Simulate some time passing
    this_thread::sleep_for(chrono::milliseconds(100));
    
    // Acquire lock to update the key-value store
    lock_guard<mutex> lock(mtx);
    kvStore[key] = value;
}

// Function to retrieve a value for a given key
string getKV(const string& key) {
    // Simulate some time passing
    this_thread::sleep_for(chrono::milliseconds(50));
    
    // Acquire lock to read from the key-value store
    lock_guard<mutex> lock(mtx);
    if (kvStore.find(key) != kvStore.end()) {
        return kvStore[key];
    }
    return "";
}

int main() {
    // Initialize the key-value store
    kvStore["name"] = "Alice";
    kvStore["age"] = "30";
    
    // Simulate concurrent updates
    vector<thread> threads;
    threads.emplace_back(updateKV, "name", "Bob");
    threads.emplace_back(updateKV, "age", "35");

    // Simulate concurrent reads
    threads.emplace_back([]() { cout << "Name: " << getKV("name") << endl; });
    threads.emplace_back([]() { cout << "Age: " << getKV("age") << endl; });

    // Wait for all threads to finish
    for (auto& t : threads) {
        t.join();
    }

    // Output the final state of the key-value store
    cout << "Final state:" << endl;
    for (auto it = kvStore.begin(); it != kvStore.end(); ++it) {
        cout << it->first << ": " << it->second << endl;
    }

    return 0;
}

Explanation of the Above Code

• Global Variables: kvStore stores key-value pairs, while mtx ensures thread-safe access using a mutex.
• updateKV() Function: Updates a key-value pair with a simulated delay and locks the mutex during the update operation.
• getKV() Function: Reads a key-value pair with a simulated delay and locks the mutex to ensure safe access.
• main() Function: Initializes the key-value store, creates threads for concurrent read/write operations, waits for all threads to complete, and displays the final contents of the store.

Challenges of Eventual Consistency

Eventual consistency offers high availability and scalability, but it introduces several challenges:

• Complexity: Managing data synchronization across multiple nodes and replicas can be difficult.
• Concurrency & Conflict Resolution: Simultaneous updates may create conflicts that require careful resolution to maintain correct data.
• Latency: Updates may take time to propagate, causing temporary inconsistencies between replicas.
• Weaker Guarantees: The model does not guarantee when all nodes will become consistent, which may not suit applications requiring strict consistency.
• Risk of Data Loss: Incorrect propagation or poor conflict handling can potentially lead to lost or inconsistent data.