Eventual Consistency in Distributed Systems | Learn System Design

Consistency in a distributed system refers to the property that the data stored on different nodes of the system is always in agreement with each other. In other words, all nodes in the system have the same view of the data at all times.

What is the Importance of Data Consistency?

Data consistency is crucial for ensuring that all users and systems have access to the same, up-to-date information. It helps prevent errors, confusion, and conflicts that can arise from inconsistent data. Consistent data also ensures that business processes run smoothly and that decisions are based on accurate and reliable information.

What is Eventual Consistency?

Eventual consistency is a consistency model used in distributed systems where, after some time with no updates, all data replicas will eventually converge to a consistent state. This model allows for replicas of data to be inconsistent for a short period, enabling high availability and partition tolerance.

• Eventual consistency guarantees that if no new updates are made to the data, all replicas will eventually converge to the same value, even in the presence of network delays or temporary partitions.
• While it may lead to temporary inconsistencies, eventual consistency is suitable for scenarios where immediate consistency is not critical, such as in social media feeds or shopping carts, and provides a balance between consistency, availability, and partition tolerance in distributed systems.

Characteristics of Eventual Consistency

The characteristics of eventual consistency include:

• Asynchronous Updates
  • Updates to the system are not immediately propagated to all nodes.
  • Instead, they are propagated asynchronously, which can lead to temporary inconsistencies between nodes.
• Lack of Strong Consistency Guarantees
  • Eventual consistency does not provide strong guarantees about when updates will be propagated or when all nodes will converge to a consistent state.
  • Instead, it guarantees that given enough time and no further updates, all nodes will eventually converge to a consistent state.
• Delayed Propagation
  • There can be delays in propagating updates across nodes, which can result in temporary inconsistencies where different nodes have different views of the data.
  • These inconsistencies are resolved over time as updates are propagated and applied to all nodes.
• Conflict Resolution
  • In cases where conflicting updates occur (e.g., two nodes update the same data concurrently), eventual consistency requires a conflict resolution mechanism to resolve the conflict and ensure that all nodes eventually converge to a consistent state.
• Eventual Convergence
  • The key characteristic of eventual consistency is that all nodes will eventually converge to a consistent state, given enough time and no further updates.
  • This means that temporary inconsistencies are resolved over time, and the system eventually becomes consistent.
• High Availability
  • Eventual consistency can improve system availability by allowing reads and writes to continue even in the presence of network partitions or node failures.
  • Clients can continue to access the system and perform operations, even if some nodes are temporarily unavailable.

Real-Life Example of Eventual Consistency

Imagine you add an item to your shopping cart and then quickly check the cart to see if the item is there. Due to the distributed nature of the system, the cart information might be stored on different servers, and there could be a delay in updating all servers with the latest cart information.

• In this scenario, you might see the item in your cart on one page but not see it on another page or when you refresh the page.
• This is because the server you are accessing might not have received the latest update yet.
• However, the system is designed to eventually propagate the update to all servers. So, even though there might be a temporary inconsistency where some servers have the updated cart information and others don’t, eventually all servers will have the same cart information.
• This example illustrates how eventual consistency allows the shopping application to handle updates to the cart in a distributed environment, ensuring that all servers eventually converge to the same state.

Note: Eventual consistency is often used in systems that prioritize availability and partition tolerance over strict consistency.

How Eventual Consistency works?

1. Write: A client sends a write request to a single replica (server node).
2. Local Update: The replica immediately commits the update locally, making it accessible to local reads.
3. Replication: The updated data is then sent asynchronously to other replicas through a chosen mechanism, like:
   • Message Queue: The update is pushed onto a queue, and different replicas pull and apply updates at their own pace.
   • Replication Protocol: A specific protocol dictates how updates are exchanged and applied, ensuring correctness and avoiding conflicts.
   • Gossip Protocol: Replicas periodically exchange information about their data, eventually converging to a consistent state.
4. Inconsistency Window: During replication, different replicas might hold different versions of the data, creating an “inconsistency window.” This window varies based on factors like:
   • Network Latency: How long it takes messages to travel between replicas.
   • Replication Frequency: How often updates are sent and received.
   • Workload: The overall load on the system can impact replication speed.
5. Convergence: Eventually, all replicas receive and apply the update, closing the inconsistency window and achieving consistency.

Use-Cases of Eventual Consistency

Below are the usecases of Eventual Consistency:

• Social media
  • Real-time updates are prioritized over guaranteeing everyone sees the exact same feed at the same moment. 
  • Short-term inconsistencies in likes,comments, or follower counts are less critical than keeping the platform responsive.
• E-commerce websites
  • Showing accurate product availability is crucial, but a momentary delay in reflecting sold-out items is less detrimental than slowing down the entire website due to strong consistency requirements.
• Content delivery networks (CDNs)
  • Delivering cached content quickly to users worldwide takes priority over ensuring instant updates across all servers. 
  • Eventual consistency ensures content eventually reaches all locations without sacrificing performance.
• Log aggregation
  •  Data from various sources gets collected and processed asynchronously. 
  • While some logs might not be immediately available for analysis,eventual consistency ensures all data eventually gets incorporated for accurate insights.
• Big data analytics
  • Processing massive datasets often involves distributed systems where eventual consistency allows efficient analysis without sacrificing performance at the cost of slight delays in seeing updates.
• Email delivery
  • Ensuring emails reach recipients quickly is more important than showing a “sent” notification instantly.
  • Eventual consistency allows for fast delivery while the sent status propagates across systems.`
• Stock market data
  • While real-time information is valuable, a few seconds of delay due to eventual consistency is acceptable in most cases as long as the data eventually reflects accurate trades.
• Online gaming
  • Maintaining smooth gameplay takes priority over ensuring everyone’s game state is perfectly synchronized. 
  • Eventual consistency allows for responsive gameplay while eventually converging to a consistent state.

Impact of Eventual Consistency on (System performance, Scalability, and Availability)

Eventual consistency can have both positive and negative impacts on system performance, scalability, and availability:

Positive Impact

• System Performance: Eventual consistency can improve system performance by allowing writes to be processed quickly without waiting for updates to be propagated to all nodes. This can reduce latency and improve responsiveness.
• Scalability: Eventual consistency can improve scalability by allowing systems to scale out horizontally, adding more nodes to handle increased load. Since nodes can process writes independently, the system can handle a larger number of concurrent operations.
• Availability: Eventual consistency can improve availability by allowing systems to remain operational even in the face of network partitions or node failures. Clients can continue to read and write data, even if some nodes are temporarily unavailable.

Negative Impact

• System Performance: The need to resolve conflicts and ensure eventual consistency can introduce overhead and complexity, which can impact overall system performance.
• Scalability: Ensuring eventual consistency across a large number of nodes can be challenging and may require additional coordination and communication, which can limit scalability in some cases.
• Availability: Ensuring eventual consistency requires nodes to communicate and synchronize updates, which can increase the risk of conflicts and inconsistencies. In some cases, this can lead to degraded availability if conflicts are not handled correctly.

Differences between Eventual Consistency and Strong Consistency

Below are the differences between Eventual and Strong Consistency:

Aspect	Eventual Consistency	Strong Consistency
What it means	Data will be consistent eventually, but there might be a short delay before all copies are updated	Data is always consistent, with updates immediately visible everywhere
When it’s used	Good for things like social media feeds or shopping carts, where a slight delay in consistency is okay	Needed for critical things like bank transactions, where all copies must be consistent at all times
How it works	Data updates are allowed to happen without waiting for all copies to update immediately	All copies of data must be updated at the same time, which can take longer and require more coordination
Dealing with conflicts	May need to resolve conflicts if different copies are updated at the same time	Conflicts are rare because all copies are updated together
Use Cases	Suitable for applications where immediate consistency is not critical, such as social media feeds, shopping carts	Critical for applications where strong consistency is required, such as financial transactions
Performance Impact	Generally provides better performance and scalability due to relaxed consistency requirements	May introduce higher latency and overhead due to coordination and synchronization requirements

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.

Below is the code of Eventual Consistency

C++

#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;
}

Below is the explanation of above code:

• Define Global Variables:
  • kvStore: An unordered map used as a key-value store to store string key-value pairs.
  • mtx: A mutex used for thread safety to protect concurrent access to kvStore.

• updateKV Function:
  • Simulates an update operation by updating a key-value pair in kvStore with a delay of 100 milliseconds.
  • Acquires a lock on the mtx mutex before updating to ensure only one thread can update the store at a time.
• getKV Function:
  • Simulates a read operation by reading a key-value pair from kvStore with a delay of 50 milliseconds.
  • Acquires a lock on the mtx mutex before reading to ensure only one thread can read from the store at a time.
• Main Function:
  • Initializes the key-value store kvStore with some initial values.
  • Creates threads to simulate concurrent updates and reads to the store.
  • Waits for all threads to finish using join().
  • Outputs the final state of the key-value store.

Benefits of Eventual Consistency

Below are the benefits of Eventual Consistency:

• Improved Performance: Eventual consistency allows for better performance in distributed systems because it reduces the need for immediate coordination and synchronization of data updates across all nodes.
• Increased Availability: Since eventual consistency allows for temporary inconsistencies, it can improve system availability by allowing operations to continue even if some nodes are temporarily unavailable.
• Scalability: By relaxing the requirement for immediate consistency, eventual consistency can improve scalability in distributed systems by allowing for more parallel and asynchronous operations.
• Reduced Latency: Since updates do not need to be immediately propagated to all nodes, eventual consistency can reduce latency for write operations, improving overall system responsiveness.

Challenges of Eventual Consistency

Below are the challenges of Eventual Consistency:

• Complexity: Implementing and managing eventual consistency can be complex, especially in distributed systems with multiple nodes and data replicas.
• Concurrency Control: Coordinating concurrent writes and ensuring that conflicting updates are handled correctly can be challenging, leading to potential data inconsistencies.
• Conflict Resolution: Resolving conflicts between concurrent updates requires careful handling to ensure that the final state of the data is consistent and correct.
• Latency: There can be latency in propagating updates across nodes, leading to temporary inconsistencies where different nodes have different views of the data.
• Guarantees: Eventual consistency does not provide strong guarantees about when updates will be propagated and when all nodes will converge to a consistent state, which can be challenging for applications that require strong consistency guarantees.
• Data Loss: In some cases, eventual consistency models may lead to data loss if updates are not propagated correctly or if conflicts are not resolved properly.