‫Consistency is the property of having expected results in the view of the data or during reads while
‫working with a database system, it is one of the acid properties in relational database systems.
‫Eventual consistency is another term that was born recently, specifically as a no sequel.
‫Databases started to emerge.
‫And this video, we will discuss and talk about the different kind of consistencies and we will explain
‫what eventual consistency mean, how both actually relational databases and also equal databases suffer
‫from this eventual consistency.
‫And this is something that is not very clear out there.
‫So a lot of people think that eventual consistency is something for just not equal.
‫Right.
‫But that's not entirely correct.
‫If you want to find out how that is the case, stay tuned.
‫This agenda.
‫Here's all I want to talk about today.
‫In order to talk about eventual consistency, I really need to talk about consistency.
‫And I have two types of consistency here to discuss.
‫And it's very critical to disambiguate this these two types of consistencies.
‫And then we're going to talk about eventual consistency.
‫But let's let's learn about consistency first so you can have consistency in your data or consistency
‫during the reads.
‫And these are two separate concepts that we really need to understand.
‫I'm going to talk about each of them now, consistency in the data specifically.
‫Let's take an example here.
‫And it emerges when you have multiple reviews and representation of your data, especially with multiple
‫tables, four and Keys joins, that kind of consistency emerges when you have these multiple collections
‫of data that represents kind of the same unit when you have essentially a normalized view of your data.
‫That's setting an example.
‫Let's say this is Instagram.
‫I have a table called pictures.
‫I have an idea of the picture, the blob and the total number of likes that this picture received.
‫And there is another picture, another table that actually list all the users who liked what pictures
‫make sense.
‫So theoretically, these two views present the same thing, which is a picture and users.
‫Right.
‫But in reality, those two better be consistent.
‫Right.
‫That means if I picture one got to likes them and if I go to the other table, there must be two records.
‫So that's a consistent view of the data itself.
‫And there are a lot of things that ensure this kind of consistency, especially when you're updating
‫multiple things and data.
‫Relational databases are great for this, especially with that tomasetti and isolation and make sure
‫that you're touching as much as stable as possible and is going to ensure that consistency for you in
‫the data.
‫Let's talk more about that consistency in the data as defined by the user.
‫I split those two views into two multiple tables, pictures and the user like balance sheets and the
‫sales, all the stuff.
‫You split it up and you normalize your database the way you want, but is essentially defined by you
‫as a as a user.
‫And the user is essentially whoever designed the database.
‫Right.
‫You get a differential integrities.
‫You get the foreign keys that represent those tables, you delete one if you delete the picture.
‫Right.
‫And the back example, if I deleted this picture, all those records will go away.
‫Right.
‫If you have Cascade's set on your foreign keys and all these things that ensure your consistency in
‫your data and that view, the simple view, narrow view, get almost at and isolation are two properties
‫of the database relational database that ensures, if you think about it is consistent.
‫And we talked about this, but essential items, atomizers like all or one.
‫If you have a transaction with multiple queries touching multiple tables, all of those should fail.
‫Right?
‫If one of them fail and if all of them succeeds, that gets committed n equal databases.
‫Most of them do not have that at Tomasetti on different views.
‫They have a Tomasetti on a different set of collection.
‫If you're updating a collection, that's all you get.
‫If you're touching other stuff, you cannot really ensure that the material, that isolation is the
‫ability is like a fireman and flight transaction can changes to other stuff being seen by me, like
‫of other transactions are executing transactions or changing.
‫Can I see these changes in the same time?
‫And that obviously leads to inconsistent reads, inconsistent results.
‫We talked about that and the other video as well, different finizio.
‫Repeatable, read and noncommitted and all that stuff serialisation.
‫Let's talk about the second type, the read, the consistency.
‫If I have a database here and I say, hey, database update this field, set it to field to value X,
‫OK?
‫And then if I do that, that value will be updated X and consistency and read is nothing.
‫But if a transaction now comes and try to read the value, it better get that new value.
‫That's what consistency in reads me.
‫Now we would say, Hussein, what are you talking about?
‫Of course that makes sense.
‫Yea, if I updated that value of course the new transaction will pick it up.
‫What are you talking about.
‫Right.
‫This type of consistency, relational databases and no SQL databases suffer from this.
‫Right.
‫We cannot guarantee this if we have one database.
‫Life is dandy, right.
‫If you have one server, everything is nice and easy.
‫Relational database is the best if you have one single server.
‫But that's in reality, you never have one server.
‫If you have like a million user, you need to scale lots of wreathes, lots of updates.
‫You're going to add caches, you're going to add nodes, follower nodes.
‫You're going to become you have a one leader node and one multiple follower nodes.
‫And and those follower nodes will take on your knees and you will have one reader or leader, right.
‫Or node.
‫Right.
‫Let's take an example and talk about this eventual consistency concept.
‫Right.
‫In reads, essentially.
‫OK, so now let's say I have this master node or the leader node and then you have to follow or nodes
‫here.
‫OK, that is essentially just getting whatever the master node or the leader nugget's, it will just
‫they follow the values and will get propagated.
‫Those values will be propagated to those follower nuts.
‫And we point the readers to this database so we can offload this huge number of these million users
‫to these databases, put them behind bars or something, and then just offload these huge number of
‫rates.
‫OK, sounds good.
‫Let's say I want to update Z, the values.
‫Now, this is a consistent view.
‫All of these databases are these right.
‫Have a value of Z.
‫I'm going to update it X.
‫Right, OK.
‫So sweet.
‫My leader node now have a value of X, but guess what?
‫At the same time some read someone started to read that value but they got what they got Z.
‫So now this system is inconsistent to me.
‫Right.
‫It's not consistent.
‫Despite that being relational database, this is a postscript database, right?
‫Three politicus instances, it's not consistent.
‫It is eventually consistent.
‫And we're going to talk about that.
‫So we read that we got an old value.
‫We just broke our rule.
‫But we said when I write something and I another transaction, read it, I better get the latest value.
‫It did not.
‫And that is why we are inconsistent here.
‫In this case, this poor slob got an old value that maybe that's OK.
‫But we're just saying now with time.
‫X or the leader, no, we'll stop pushing the new value to the fellow or not.
‫This guy will push the new value now and consider new reads, will start reading the new value.
‫So that's what eventually consist of consistent systems.
‫And this is this is a problem that is in both nonsexual, equal and relational.
‫So eventual consistency is not something for no SQL databases, guys.
‫OK, so we need to really clarify that at first.
‫What do you mean when you say consistency?
‫Right.
‫What do you mean by a consistent system?
‫Are you talking about the read or are you talking about the actual value of the data?
‫Is the consistency from the data itself?
‫Are many different tables because that's great.
‫Yeah, that update might touch seven tables in an atomic manner, in an isolated manner.
‫And that view is consistent in this database.
‫But the whole system to the user, it is not consistent because you introduce those new hobs, the same
‫thing with if you introduce in a cache like a Redish or Memcache D, right the moment you introduce
‫a cash.
‫You're inconsistent whenever you have a cash, you're inconsistent because you will remain inconsistent
‫unless you update the cash.
‫Once your data has two places you're inconsistent, you will become eventually consistent, which is
‫this is this is just a marketing term to me, right?
‫Yeah, of course.
‫It's eventual consistency.
‫And this gets yeah.
‫Eventually these values will get it.
‫But it's up to you now as a user, as a software engineer.
‫Can you tolerate that?
‫Is that OK?
‫If the user read a value and they got 7000, 7000 likes instead of seven thousand eleven likes.
‫Right on Kylie Jenner's latest picture.
‫OK, maybe not.
‫I don't care.
‫Right.
‫I don't care if that egg picture got three million and 20 hundred thousand views that even a number
‫right on a picture versus the second person.
‫Actually God like I don't know, another an extra fifty thousand likes extra.
‫It doesn't matter.
‫Sometimes it doesn't matter.
‫Sometimes it does matter.
‫If I updated my balance.
‫Right, if I deposited thousand dollar I better see that thousand dollar.
‫Right.
‫If I withdrew some.
‫If I say if I withdrew some money.
‫Right.
‫And let's say at the same time I did double withdrawal, double spend and I end up with two thousand
‫dollars.
‫Why I have only one thousand dollars in my account.
‫That's an inconsistent it's good for me because I was able to check the bank and draw two thousand dollars
‫while I have only one thousand.
‫Right.
‫Because of this inconsistency.
‫And that's something bad.
‫Right.
‫So that's eventual consistency and.
‫All right, let's talk more about the consistency and if a transaction committed a change, well, a
‫new transaction immediately could see that change.
‫That's what that's what a consistency in reads mean.
‫It's a different than inconsistency in data.
‫I don't know if there are times I made those two terms up.
‫OK, this is the real thing.
‫I don't know if they have an actual scientific term.
‫Right.
‫But what what do you think about it?
‫That's the only thing I can think about it.
‫There's a data consistency and there is a real consistency.
‫And you have to clarify that the difference is it's a problem in both equal, not equal and relational.
‫Right.
‫As long as you want to scale horizontally and reduce gadgety right weather with no equal databases.
‫And if you have Scharpling, that's a different story.
‫We're not going to talk about Sharding in this video.
‫Right.
‫But that's in a nutshell.
‫The moment you introduce gashing or you try to scale horizontally by adding some follower nodes, you
‫are inconsistent.
‫That's eventual consistency and show.
‫So summary, what did we talk about?
‫We talked about consistency, talked about the different two types of consistency.
‫Right.
‫We talk about consistency in the data.
‫We talked about consistency in REDESCRIBE.
‫We talked about the how those two differ.
‫Right.
‫Consistency in the data is guaranteed by this property that's called a Thomas City and isolation and
‫even durability, if you think about it.
‫Right.
‫So it's like if you if I commit and I read again, a better be there.
‫Right?
‫If it's not there, then it's not durable, then it's not consistent if you think about it.
‫And eventual consistency is the ability to for the reads only write.
‫This is a point I forgot to mention.
‫If you screw up your atomic transaction, you have seven tables.
‫They have to stay consistent together.
‫Right.
‫And you updated three and you got blue screen of death.
‫There is no eventual consistency coming out of that dude.
‫You just screwed you corrupted your database.
‫There is no overall consistency in that.
‫If you do not have a Tomasetti, you do not have eventual consistent.
‫You do not have consistency at all.
‫Consistency in Reed is different than consistency in the data.
‫It is a I sure I'm going to commit that eventually that the follower, not if it's offline, I'm going
‫to come online and is going to pick up the new data.
‫That's OK.
‫We know that's going to be because we know that this site, we guaranteed that consistency at that leader
‫node.
‫But the moment you screw up, you don't have isolation, you don't have proper automaticity, you don't
‫have durability.
‫No eventual consistency can actually help you here, my friend.
‫All right.
‫So you just your data is done, OK?
‫You have corrupted inconsistent data.
‫If you have inconsistent data, there is no point of doing an inconsistent read because your view will
‫always be inconsistent no matter how long you waited.
‫And I'm going to see you in the next one.
‫You guys stay awesome.