Consistency in Database
In this blog, we will learn data consistency in the databases, and when to use which type of consistency. Data Consistency became a very important aspect when we deal with Microservice Service architecture because in single database system ACID properties can be enforced easily by creating proper relationships and setting proper constraints.
Introduction
While using the Microservice architecture pattern, developers need to implement a feature that will ensure data consistency in services because the traditional ACID transaction approach cannot be used. The ACID approach is only applicable when data for all services is stored in a single database. In Microservice architecture, usually, each service has its own database. Though it is not necessary, some services can share databases. Having a database per service offers complete independence.
In any system there are two types of consistencies:
- Eventual Consistency
- Strong Consistency
Eventual Consistency
It is the behavior of a service that allows sending a success response back to the user before data is written in every datastore. The eventual Consistency concept is not tied to Microservice architecture. Let’s see different usage of eventual consistency.
- It can be used when we have multiple replicas of databases in Monolithic Architecture.
- It can be used if a system has multiple read/write copies of the databases.
- It can be used in Microservice Architecture where some tables are utilized by multiple services.
Strong Consistency
It is the behavior of a service that enforces to send success response back to the user only when data is written in every datastore which acts as a source of truth.
Type of Data
Broadly speaking, the system interacts with two types of data in any datastore:
- Transactional Data
- Non-Transactional Data
Transactional Data is usually comprised of data generated by the Core functionality of a system. For e.g., in the e-commerce system, all purchases, return refunds data.
Non-Transactional Data is usually comprised of data generated by functionality that are developed to provide support to core functionalities. For example, in our e-commerce system, all purchase, return and refund functionality need user and item information. So, in this case, user and item data are non-transactional data.
Guidelines to choose correct Data Consistency Pattern
Now, we have an idea about data, let’s understand the guidelines for consistency:
- For non-transactional data, we can have eventual consistency.
- For transactional data, we generally use a combination of strong and eventual consistency. The datastore acting as a source of truth should implement strong consistency. And all other datastore that depends on transactional can implement eventual consistency.
As a general rule of thumb, we should implement eventual consistency because it facilitates decoupling in the system.
I hope this blog helps you understand the concept of data consistency in any system.
Comments and feedback are most welcomed.
Follow me on Linkedin, Github, Medium Thanks for reading. Happy Learning 😊
