Earlier this year I started development on a reference microservice based architecture on containers to familiarize myself with new patterns I have been hearing about over the last year or so. This application is Med Park 360. In a previous blog post about CQRS I mention eventual consistency but felt it needed it’s own post so that we can dig a little deeper.

Explain it to me like I’m five

Eventual Consistency is a characteristic of mainly distributed systems in that the value of a specific data item will, in time, be consistent across all nodes of your application. Eventual consistency is also known as optimistic replication.

Let’s go back to my reference application, Med Park 360. We can use a business process I have implemented here to give you a working and better grasp of what Eventual consistency is.


On Med Park 360, registered patients have the ability to place orders for medication prescribed to them by their respective specialists. To accomplish this, multiple services are invoked from selecting the products, all the way up to processing payments. In the Med Park Example, The services to be used for this specific business function would be the Ordering and Payment services. For this post I will only be referring to the Order Service. So once an Order has been placed the patient will be redirected to the Payment portal to complete the payment for said order. Depending on how you have bounded you contexts, in my case, the Order entity Model resides in multiple services. The Order services of course, but also the Payment and Customer services respectively. So whenever I update my order in the Order service, the same has to be done for the order in the Payment or Customer services, thi sprocess is known as Eventual consistency.

Once the status of the Order has been updated to Payment Received in the Payment Service, the data will then be updated in the Order service as well as the Customer service. During this time, the status of the order would still be Order Placed. But when using this approach, we can be certain the data will eventually be the same. This does mean that if we were to get the Order status from one of the services the data might be stale, hence eventually.

Eventual consistency offers low latency at the risk of returning stale data.

In distributed computing environments, the CAP theorem postulates that it is impossible to simultaneously guarantee consistency, availability and partition tolerance (CAP) and that administrators have to select the two out of three that are most important to them.


In conclusion, while Eventual Consistency offer low latency, you have to accept the risk of replying to requests with stale data as the data residing on multiple nodes may not have been updated by then.

I hope this helped you on your Distributed Systems design journey.