Eventual Consistency in Microservices and Large-Scale Distributed Systems

You can listen to the audio of this blog here

What is consistency?

Consistency is one of the most important aspects of system design. Consistency refers to the uniformity of the data presented to the user across all services and systems in a Distributed System.

Before moving on let me define a Distributed System

What is a Distributed System?

Imagine you have an application - for example an online product delivery app. All the operations in this application take place on a single server. As you get more orders, your server is unable to handle the load.

So now you decide to separate the operations of the system into multiple services. If required, you can scale up each service individually. This collection of multiple services that are part of a single application is called a distributed system.

Since the operations are distributed in different services/systems, we call them distributed systems. We call it large-scale distributed systems as it happens on a large scale.

These individual services are also called micro-services.

Now coming back to "What is consistency?"

Suppose in the above product delivery app, there are 2 services -

Service 1: Add/Edit/Delete items to the cart

Service 2: Fetch the cart details

For a user, he sees a single application, but for the application, all this work is divided among various services. Suppose the user adds a book to the shopping cart.

Service 1 goes and updates its database. It will also tell Service 2 to update its database and then it will return a success message to the user.

In this configuration, service 2 is aware of the changes made by the user. Hence it will always reflect the latest changes made by the user. Since there is uniformity in data across all services, we call this a consistent system. This type of consistency is called strong consistency as the system is consistent every time.

Now consider this -

Database write operations are time taking and in this process, the user had to wait for both service 1 and service 2 to update its database. You want your application to be faster. So you decide that as soon as Service 1 updates its database, you return a confirmation to the user. The update to the Server 2 will be an async background process.

This means that at the time the user got a confirmation, service 2 would still have given an incorrect result. Because of this, the system is not consistent. But there's a catch. Since this service has a background job to update the database of Service 2 eventually, we can say that such a system has eventual consistency.

Eventual consistency is a type of database that is not consistent, but reliable. It guarantees that the data will eventually be in the same state. This means that it may take time for the data to synchronize, but it will eventually happen.

In eventual consistency, the system guarantees that the latest write to any object will be eventually reflected in all copies of it, but it might take some time.

Eventual consistency is not suitable for applications that require strict ordering of events and need to maintain data integrity. It can also lead to a lot of trouble when you are trying to build a system with many replicas.

This is one of my favourite comic strips that explains eventual consistency

And that's a wrap! Hi, I am Gourav Dhar, a software developer and I write blogs on Backend Development and System Design. Subscribe to my Newsletter and learn something new every week - https://thegeekyminds.com/subscribe