in this lesson we will look at consistency models these are very crucial while designing your system a distributed system uh so let's see what our consistency model and what are the different types of consistency that we need to consider so in the context of a distributed system a consistency can mean different things one is that each replica node has the same view of data at any given point of time so let's say we have three nodes replica nodes N1 N2 and three then at time t for any given let's say variable or should have the same value for all the replica nodes other definition could be that each read request gets the most recent value of right so let's say the value of x was updated somewhere at some node let's initially it was 10 now it's 20. and node N3 tries to fetch the value of x so it should get the value of 20 and not the old value but this is not true for all types of consistency models it will be the case of a strict consistency so uh it's often the case that when you are designing your application you require third party systems that you can integrate into your system then you should need you should look at the consistency guarantees provided by that system so some systems May guarantee eventual consistency but they may not guarantee the strict consistency and we will see what are these eventual and strict consistencies so you should have a look at that if you need a strict consistency but the system that you plan to use only guarantees eventual consistency then better not to use that in your system as that may not fulfill your requirements so now let us see the different types of consistency models so these are the four types there can be many more ways of defining consistency so you can have many more models but let's categorize them into these four broad categories and the strictness is in this order as you can see strict is the last one so this is in order so this is the least strict this is the next higher more strict and more and most strict it's also called linearizability so let's start with eventual consistency so it is the weakest form of consistency and all replicas will have the same value of read request but not simultaneously eventually they will get the updated value so since strict consistency is not required here these systems generally are highly available you don't need to wait uh you don't need to uh stop the request if there is any update it's not required that you get the latest update update of that value so you can return the previous value older value so the system is always available highly available so one of the example is then that domain name systems servers use eventual consistency and similarly Cassandra users eventual consistency and these guarantee High availability so cash Android no SQL database uh one practical example can be that let's say your uh some of the videos that you watch on YouTube or you will see some views below that video when you are watching any video so let's say it's showing 1000 views but in reality there may be let's say 1020 views but it's not reflected in real time it's okay for some other viewer maybe that if they are fetching data from some other node they may be seeing 110 views for that videos But ultimately uh it's kind of they will sync and they will get the latest value but not in real time so this is okay this does not break anything any of the requirements of the system for YouTube so this is the eventual consistency model and then let's look at causal consistency so it's slightly stronger stronger than eventual but still it's considered as a weak consistency so it preserves the order of causally related or dependent operations so let us say operation a is dependent on B or rather B is dependent on a and there is another operation C which is not dependent on these so among A and B a should be done first so a b should be updated once the value of a is updated so B should be calculated based on the latest value of a so here B is causally related to a but C is not related you can get the old value of C or so here ordering is not defined among non-causi related operations but among causally related operations let us say there is another operation D that depends on B so here there is a ordering so this ordering is maintained but other operations ordering is not defined so it doesn't ensure ordering of operations that are non-causal so one of the Practical examples would be that comment replies so again taking the example of YouTube video or any other LinkedIn post or a Facebook post so there is a video YouTube video playing here then below that you also have comments so some person a or ABC posted some comment comment one and somebody you can also reply to a comment so there is a reply button here there are of course like and like buttons also so if somebody replies to this comment one so that is let's say reply one so here comment one should come before reply one and not that reply one comes appears in this comment section and somewhere down comment one appears so this is not accepted since this reply was for the comment one there are other comments comment two three but this reply was specific to comment one so it was dependent on comment one so here we should maintain the ordering or it's possible that some person posted comment 2 which was very slightly later than comment one but that occurs first so that is okay that does not break anything unless that comment depends on comment one of in that case it should be a reply so this is causal consistency now let's see the third consistency model that is sequential consistency so it's even stronger than causal consistency and it preserves the ordering specified by each client program so it doesn't tense your rights are visible instantaneously or in the same order as they occur According to some Global clock so there are multiple programs running and within a program it should maintain the same order in which they occurred but if you look at from the point of global clock then that is not guaranteed for example let us say you open your Facebook you log into it and you see the posts from different friends so this is friend one this is front two front three front four you see posts in this order of course friend one may have multiple posts so it's okay if friend trees posts occur earlier in your timeline but if you look at any friends posts uh within that if friend one posted three comments three posts then it should be in that order it should not be that friend one posted uh this P1 first but it's occurring in the middle so for that friend it should be in order but overall it's okay friend three post occurs first and then friend one so that is sequential consistency uh so now let's look at the final and most strict consistency model it's also called linearizability so it's the strongest and read requests from all the replicas get the latest write value so uh so if there is any client that updated the value so there is a acknowledgment that the right has been done only after the acknowledgment is received other clients can read the value so this is this is how Street consistency can be ensued and as a result the availability may be uh lower than a weaker consistency models so uh for example if you have some security concern then you update your password for your bank account then any other device or any other location should not uh so if somebody tries to log into account from using the old password it should be instantaneous or somebody should not be able to log in with the older password irrespective of whether they are in the same geographical location or some other location or same device or other device it should be strict in that case otherwise it's not secure so in that case you need to if you want to use any system third party system ah that does not guarantee strict consistency then you cannot use that in your system design another example is Amazon aura that ensures strict consistency so these were the major consistency model I hope you keep in mind these consistency considerations while designing your next system