In this article, we have explained Consistency Pattern in System Design along with examples for different types like Eventual, Strong and Weak Consistency.

Table of content:

1. Need for Consistency
2. Eventual Consistency
3. Strong Consistency
4. Weak Consistency

Need for Consistency

Companies like Google, Facebook or any company in today's world have multiple servers since it is neither efficient nor palatable to have one server.
Moreover, there are different servers based on the geo-location of the user.
Consider a scenario where data stored is stored only in the nearest server to the user, say in India.

If another user, say from Japan, tries to access the data, he will not find it.
So for the data to be available, it is necessary to copy it to different servers (Yes, multiple servers!).

Now comes the question of how to write data to multiple servers. A user will write data to the server he connects. From the server, it needs to write to other servers.
With multiple copies of the same data, We need to write data at multiple places and all these places must be in sync so clients have a consistent view of the data. This brings us into the domain of Consistency.

There are three types of Consistency:

• Eventual
• Strong
• Weak

Eventual Consistency

In Eventual Consistency, after a write, reads will eventually see it ( within a few milliseconds).
Let's understand this using an example.

User A writes a value X to a server in India. Here, a value X can be a photo, video, text or anything else.
Data from Node A is replicated to Node B. Read request by User B gives response as X. However, the read request by User C gives a response as Xold( old value of X). The data in Node C will eventually be updated to the latest copy.

Uses: DNS and Email

Example: User A (say in India) sends an email to User B (say in Japan). If User B checks his email he will not be able to see the email immediately. When the data from Node of User A gets replicated User B can see the email. The data will be eventually updated to the latest copy. Here, there is no need for data to replicate immediately, but it must replicate.

The Internet Domain Name System (DNS) is a well-known example of a system with an eventual consistency model. DNS servers do not necessarily reflect the latest values but, rather, the values are cached and replicated across many directories over the Internet. It takes a certain amount of time to replicate modified values to all DNS clients and servers. It is highly available and has proven to be extremely scalable, enabling name lookups to over a hundred million devices across the entire Internet.

Strong Consistency

In Strong Consistency, after a write, reads will see it. Data gets replicated synchronously. It is also called strict consistency.
Let's understand this using an example.

User A writes a value X to a server in India. Data from Node A is replicated to Node B and Node C. If during replication any user requests data, the request gets blocked. Data viewed after replication will always be consistent.

To have strong consistency, developers must compromise on the scalability and performance of their application. Simply put, data has to be locked during the period of update or replication process to ensure that no other processes are updating the same data.

Uses: RDBMS and Filesystems.

Weak Consistency

In Weak Consistency, after a write, reads may or may not see it. Here the focus is on "fast access".

Unlike Eventual and Strict Consistency, which have well-defined rules for updating the data on nodes, Weak Consistency has no such rules. Different nodes can return different values. In the long term, all updates propagate to all nodes.

Uses: VOIP and Video Chat

Example: User A and B are talking over a call. If due to some network problem User B gets disconnected, User A will not see the messages(voice or video). When User B reconnects he will not see the messages. In a Video or voice call, if you get disconnected, you will not see the conversations.

With this article at OpenGenus, you must have a strong idea of Consistency patterns in System Design.