Understanding Eventual Consistency

When we talk about a good and reliable back-end, one of its most crucial points is scalability.

The points that are boarded on this article:

1. Distributed Systems
2. Distributed Databases
3. Eventual consistency
4. Cron-jobs and Time Events
5. Final considerations

Distributed Systems

A application that depends on one or more services or systems is known as a distributed system. The name comes from the fact that the program needs of more than a system for its full functionality.
The advantage of building a distributed system is that all of your ecosystem can work independently. So, if the Users service crashes, the Posts service will stay working well, because it does not depend on any other service to work.
Let's suppose that to create a user, the app needs to communicate two different services: the Notification service and the User service. If an exception occurs at the User service, the Notification service will keep working, but, it will not receive any response from the user creation process — the fact that a service is independent does not mean that it can works perfectly alone.

Distributed Databases

Distributed databases are the best approach when you want to cut the write queries wait time. If we recorded the User and the Notification documents at the same database, its write queue would be much more slower, but, to avoid that slowness, we can storage each entity on a different database — this way, each database would take its time to write and the queue from the User database would not be affected because of the Notification database queue.
Other good approach with Distributed databases is using a database as main database and another as backup. Your application could have a dedicated service that each hour or each 30 minutes will record all of the main database data into the backup database, preventing the data loss or providing security to critical queries, such as updates or deletes.

Eventual consistency

Knowing how Distributed Systems and Distributed Databases works, we can use both of them at our own good to create a eventual data consistency. Eventual consistency means that at some point, each one of the distributed databases would have the same content. If a app writes a document at the User database at the same time it writes a document at the Notification database, both databases would have the same content. The problem is: Wait till both databases are done writing can lasts a lot, so a solution to this problem is: Cron-jobs or time events.

Cron-jobs and Time Events

When we want to keep a Eventual Consistency between two or more databases, we need to be sure that the same data is been written on both of them, but it certainly would cause a optimization trouble. Let's avoid that problem doing an asynchronous job and create the structure the way one process would not depends of another.
The most popular approach to this problem is: creating a cron-job that looks into the data of the main database and then writes it into its related databases. So, this way, at some point, all of the databases would have the same content. And, this is why this event it is called Eventual Consistency: its consistency is eventual and it happens in a certain time frame.

Final considerations

Learning about distributed systems is a good way to improve your code quality and make sure that the base of your application will handle an enormous amount of users and not crash while a peak of usage is happening.
A good back-end only works if the infrastructure is even better.

Thumbnail by Benjamin Lehman at Unsplash.