What is consistency?
It is a hard to describe word that can be interpreted differently.
Some dictionary definitions of the word are:
- agreement or local coherence among things or parts
- correspondence among related aspects; compatibility
- reliability or uniformity of successive results or events
In short it is an abstraction to talk about the correctness of the distributed system doing concurrent reads, writes and changes/mutations.
When designing a system sometimes you have to make a call about what level of consistency is required for the solution to work properly. Depending on the requirements of the system, it might need strong consistency vs weak consistency.
ACID properties
In database systems you might have come across ACID properties.
- Atomicity: The entire transaction takes place at once or it doesn’t happen at all
- Consistency: the database must be consistent before and after the transaction
- Isolation: multiple transactions occur independently without interference
- Durability: Changes of a successful transaction occurs even if the system failure occurs
CAP theorem
You might also have heard of something called the CAP theorem.
CAP theorem states that a distributed system can deliver only two of the three desired characteristics: consistency, availability and partition tolerance. Thus you will have to design it for two of those.
- Consistency: all clients see the same data at the same time, no matter what node they are connected to. In other words, whenever data is written in one node, it must instantly be replicated to all to say that the write was successful.
- Availability: Any client making a request for data gets a response, even if one or more nodes are down.
- Partition tolerance: A partition in this context is a communications error in a distributed system. A packet loss, a delay between two nodes. Partition tolerance means that the cluster continues to work despite any number of such communication breakdowns in the system.
Read more about this in IBM Learn’s excellent guide.
Consistency spectrum
The consistency spectrum going from weakest to strongest in that order are:
- Eventual Consistency
- Causal consistency
- Sequential consistency
- Strict consistency or linearizability
Understanding this is useful and so I recommend reading this post on Consistency Models in Distributed systems by HoHuan Chang on Linkedin to understand it in depth.
Eventual consistency
The simplest way to remember is that Eventual consistency being the weakest model is a really good choice for applications that require strict ordering requirements and don’t require reads to return the latest written information. This model ensures that the replicas will eventually return the same value but there are no guarantees to the value returned being the latest one. But one can be sure that the value will eventually be the latest.
Although this might sound lame, such systems are great in terms of availability.
A great example of where this is used in real life is DNS - domain name system is a highly available system that enables name lookups to millions of devices across the internet. It relies on eventual consistency model and gradually propagates DNS changes through the internet.
Causal consistency
This is an approach where operations are categorised into dependent and independent.
Dependent operations are also called causally related operations. These preserve the order of the operations.
However, if the operations are independent then the order is not preserved.
A real world example of where this is used in a Comment and reply system. Where unrelated comments can be loaded in any order, although most people prefer to see all comments in chronologically reverse order. But let us say that there are threads in the comments, i.e replies to a comment, that would need to maintain order - this is an example where causal consistency is used and where these comment and reply scenario is a dependent operation scenario.
Sequential consistency
Preserves ordering specified by each client’s program. Doesn’t ensure that writes are visible instantly or in the same order as they occurred.
A real world example is in social media applications. Your news feed doesn’t always have to be sequential. They can appear in any order. Many friends posting at different times or timezones and even if the order is not correct you wouldn’t care. However, if you were to visit a specific friend’s feed, you’d expect their posts to be in chronological order. This is where sequential consistency is great! The application specifies the ordering.
Strict consistency or linearizable
The strongest consistency model. Ensures that read request from any replicas in the distributed system gets the latest value at all times! What does this mean and how? I mean if you had 100s of replicas, it is almost impossible to instantly replicate the value everywhere. This also comes at a cost - availability. High consistency costs availability and hence they may not always be available until the latest data is written to the database in all nodes. This also means the operations are linear and in order.
A real world scenario where this is important is user credentials - a password change operation has to be propagated instantly. You cannot allow two passwords to work at the same time. That would be a disaster. Most relational databases provide very high consistency.
Summary
I hope that helps you understand what the trade-offs are when it comes to consistency while designing distributed systems. So based on what the product requirements are, keep CAP theorem in mind and go for an appropriate level of consistency for the use-case. You can’t have it all with one system, sometimes you might have to opt for a couple of different storage options for different needs in the same product.
The point is, in a system design interview, it is your job as a candidate to highlight these and initiate these discussions.