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 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 before 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 was written by write w1, and later performs write?w2, then?w2?must be visible after?w1. This might look similar to monotonic writes, but this model is about any writes post a read, should start from the state of the read i.e Once you’ve read something, you can’t change that read’s past.

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

Read After Write Consistency

Read After Write, also known as?read your own writes, requires that if a client performs a write?w, then that same client performs a subsequent read?r, and then?r?must observe?w’s effects.

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

Eventual Consistency

Eventual consistency?is the weakest consistency level. Eventual Consistency does not guarantee the order of the data or the time it might take for the data to become consistent. As the name suggests, the system will become consistent but eventually.

Eventual Consistency offers high availability, low latency & very high throughput. It should definitely be used wherever your application does not need any ordering guarantees do not matter, i.e you can read the values older than the ones you’ve already read before.

In the next article, I will go into tuning the consistency of the application based on setting the right Consistency levels.

Thank you for reading! I’ll be posting weekly content on distributed systems & patterns, so please like, share and subscribe to this?newsletter?for notifications of new posts.

Please comment on the post with your feedback, will help me improve! :)

Until next time, Keep asking questions & Keep learning!