Database Consistency Matters !!!
Tags: discuss, tutorial, programming, database
Published: 2021-04-09 10:20:16

## The Need For Understanding 😀

The distributed databases in general are reliant on the major tuning parameters. 

Consistency is one of the key parameters used to build distributed databases.

The range of consistency tuning indicates the values to be returned from the nodes connected in the distributed cluster. 

Simply put the consistency of the database lies in the spectrum from **Strong Consistency to Eventual Consistency**.

Strong Consistency <-------------------> Eventual Consistency

The consistency level of the database defines the rules for the nodes to return a set of values that are visible to the client. This differs based on the case-to-case basis and also reliant on the application requirement.

Let me demonstrate this concept with a simple example to explain the difference between strong and eventual consistency and how to choose one over the other when you are choosing a database or even trying to build one.

## Example ⚽

Let's consider a foosball game between 2 teams Team A and Team B. It is the annual game party at your company and you are planning to develop an app to display the scoreboard.

> Team A / Team B : 0 / 0

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/q1xttr2kjmaeftrwyfyd.jpg)

Now let us assume there is a concept of scorecard status at different time intervals.
1. Initial Time (Game Started)
2. Progression Time (Game In Progress)
3. Final Time (Game Completed)

The scoreboard data is entered by you at different time intervals as the game progresses and you are required to display the scoreboard as well.

### Strong Consistency 💪

When you opt for the **Strong Consistency** things you need to take care of,
1. At any point in time, you need to display the last written value.
2. Follow Rule No.1 STRONGLY.

The example below shows the series of writes done by you on the scorecard.

```Write("TeamA", 1);
Write("TeamB", 1);
Write("TeamB", 2);
Write("TeamA", 2);
Write("TeamA", 3);```

So when the read operation is carried out at the time intervals in the cluster, the latest written value is returned. This is because we have opted for a stronger consistency.

Simply put, whenever the read operation for the scorecard is issued to your app, you need to observe the changes in all the previous or past writes in order to return the best possible output.

```InitialTime: Team A / Team B : 0 / 0
ProgressionTime1: TeamA / Team B : 1 / 0
ProgressionTime2: TeamA / Team B : 1 / 1
ProgressionTime3: TeamA / Team B : 1 / 2
ProgressionTime4: TeamA / Team B : 2 / 2
ProgressionTime5: TeamA / Team B : 3 / 2
FinalTime: TeamA / TeamB : 3 / 2```

So the best possible output for the **Strong Consistency** when the game is `In Progress` will be, 

> Team A / Team B : 3 / 2

### Eventual Consistency 🙏

Now let's consider the **Eventual Consistency** scenario,
1. At any point in time, you are allowed to display any value written in the past.
2. You are also allowed to return the initial state as well.

Now the same write operation mentioned above takes place. The read operations with Eventual Consistency provides the below possible output,

```InitialTime: Team A / Team B : 0 / 0
ProgressionTime1: TeamA / Team B : {0,1,2,3} / {0,1,2}
ProgressionTime2: TeamA / Team B : {0,1,2,3} / {0,1,2}
ProgressionTime3: TeamA / Team B : {0,1,2,3} / {0,1,2}
ProgressionTime4: TeamA / Team B : {0,1,2,3} / {0,1,2}
ProgressionTime5: TeamA / Team B : {0,1,2,3} / {0,1,2}
FinalTime: TeamA / TeamB : 3 / 2```

This example systematically explains the behavior of eventual consistency although the final state and the initial state of the game don't modify. 

So the best possible output for the **Eventual Consistency** when the game is `In Progress` will be the range of values,
 
> Team A / Team B : {0,1,2,3} / {0,1,2}

## Explore Further 🔭

If you want to know the type of consistency level opted for the different types of databases here I have linked a [one-stop solution](https://db-engines.com/en/ranking)

Select the database you want to explore from the above link and check the table for the field `Consistency concepts`. 

Some examples include,
* MongoDB, Cassandra, Dynamo DB - Eventual Consistency, Immediate Consistency
* PostgreSQL - Immediate Consistency
* Microsoft Azure Cosmo DB - Bounded Staleness, Consistent Prefix, Eventual Consistency, Immediate Consistency, Session Consistency

> Bear in mind: Strong and Eventual are not the only type of consistencies available. There are different levels of consistency that fall between the range of the spectrum that I have explained in this article. If you would like to know more about the different levels of consistencies, please do leave a comment so that I can write subsequent articles explaining them as well.

This post is a simpler version of the detailed article created by 
> Terry, D. (2013). Replicated data consistency explained through baseball. Communications of the ACM, 56(12), 82-89.)

For further detailed study visit the link [here] (https://dl.acm.org/doi/fullHtml/10.1145/2500500?casa_token=y2gj74QccgYAAAAA:AGcm-AItykXuR2hWNqQ38BPVzlZjYq69K25dTCh8Nu-XVQ8pHbNqFAy1dCm0sYS2fqJapdIRpcfeb7Q)

Photo by <a href="https://unsplash.com/@kantea?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Ak Ka</a> on <a href="https://unsplash.com/s/photos/foosball?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Unsplash</a>