Consistency Models(II): Distributed Data Stores
Session consistency models guarantee consistency constraints for any client/application session. Eventual Consistency weakest form…
Prerequisite:
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 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 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, which 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 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.