Assume there is a distributed system which works on the principles of eventual consistency.

Let's consider a scenario where I update my profile picture using my phone. If I log in using another system, let's say my personal laptop, it should show me the updated profile picture assuming it routes through the same data centre(Here I am assuming that the request will be routed to the same data centre where the write i.e. update of the profile picture was processed)

What will happen if let's say I provide my profile credentials to a friend, who lives in another country, and the request is routed to another data centre there. Will he see the updated profile picture or the old one?

For this scenario I would like to know how is eventual consistency achieved in case of multiple devices and multiple locations. For the same device/location, we can route the read requests to the same data centre where the write was processed. But I am not able to find a solution where we can handle the scenario described above.

  • 6
    Not to state the obvious, but "eventual" != "real time"
    – John Wu
    Jan 7 at 21:02

Different distributed systems try to achieve different consistency models. Eventual consistency is an extremely weak model that just says that eventually, all nodes will agree on a common state. It does not guarantee which state the nodes will agree on, or when this will happen.

In your scenario, all of the following could be observed in an eventually consistent model:

  • both persons see different profile pictures for an arbitrarily long but finite time (the nodes haven't yet reached eventual consistency).
  • the nodes eventually agree on your new profile picture. After reaching agreement, all subsequent accesses to the profile picture will see the new image.
  • the nodes eventually agree to discard your new profile picture. After reaching agreement, all subsequent accesses to the profile picture will see the old image.

Eventual consistency is a useful model for highly distributed applications but it provides really weak guarantees about updates – it is entirely unsuitable for many business processes. It is difficult to program software that operates correctly in an eventually consistent environment. Classic ACID databases are easier to reason about. However, eventually consistent systems make it easier to achieve very high availability.

This more or less boils down to the CAP theorem: you can choose any two of consistency, availability, and partition tolerance. Distributed ACID databases sacrifice availability in order to ensure consistency even in the presence of network partitions. For example, a replica node might go into read-only mode. In contrast, an eventually consistent system sacrifices consistency in order to maintain availability even in case of a network partition.


"Eventual consistency" means that the results will be consistent - eventually. In the scenario you describe, choosing an eventual consistency approach means that you accept that the results will be different for a while.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.