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

In my last article, we delved into the different consistency models within Strong Consistency and how your application consistency guarantees vary within the different consistency models.

Let’s take a look at some other consistency models and the application guarantees with those models.

Session Consistency Models

Session consistency models guarantee consistency constraints for any client/application session. This level of consistency honours the client session. It ensures a strong consistency for an application session with the same session token. What that implies is that any write done during the session will be returned by the latest version for reads, from that same session. If reads happen from a different session, the above guarantee does not hold.

In summary, session consistency provides strong consistency for the session, ensuring the data stays up to date for any active read-write session. Session consistency allows you write latencies, availability, and read throughput comparable to that of eventual consistency but also provides strong consistency guarantees for the session.

Within Session Consistency, we have multiple models as well -

Monotonic Reads Consistency

Monotonic reads guarantee that if two reads happen sequentially(R1 & R2), then R2 cannot observe a state prior to the state of R1 i.e If any writes were reflected in R1, they should also be reflected during R2.

Note that the above models only work for monotonic reads in the same session.

Monotonic Writes

Monotonic writes guarantee that if two writes happen sequentially(W1 & W2), W1’s state will always be available before W2 happens.

Note that the above models only work for monotonic writes in the same session. Writes across different sessions even if they happen sequentially are not guaranteed to be observed.

Write Follows Read Consistency

Writes follow reads, also known as session causality, ensures that if a client reads a value x, which…