Consistency Models — Consistency & Consistency Levels(II)— Distributed Data Stores

Consistency Models

In my previous article, we talked about Consistency and Consistency Levels. We also discussed that playing around with Consistency Levels allows you to tune the Consistency requirements of your application & also impacts the Availability, Latency & Throughput of your application.

In this article, we’ll go a little deeper into Consistency & Consistency Levels & talk about Consistency Models, before looking into how consistency requirements for your application can be tuned based on Consistency Levels.

Consistency Model

A consistency model is a contract between a (distributed)system and the applications that run on it. This model is a set of guarantees made by the distributed system so that the client can have expected behaviour across read & write operations.

Strong Consistency Models

As we discussed in the previous article, Strong Consistency is achieved when all replica nodes are always in sync with each other.

There are multiple models within strong consistency itself! So we’ll go through some of them in detail in this article -

Linearizability

Linearizability is the strongest form of consistency. All operations are executed in a way as if executed on a single machine, despite the data being distributed across multiple replicas. What does the above mean?

Let’s take an example. For a better understanding of Linearizability, think of everything from a client’s(Client interacting with the server/cluster) perspective.

We wrote a KV pair on my data store, at time T1 & the operation was completed at time T2.

We can now have 2 scenarios. A client can send a read request for the same key before time T2 —

Block Includes Time to Execute the Operation + Network Latencies & Other Overheads.

Or, the client can send a read request for the same key after the time T2.