1
00:00:00,570 --> 00:00:06,510
‫Consistency is the property of having expected results in the view of the data or during reads while

2
00:00:06,510 --> 00:00:13,020
‫working with a database system, it is one of the acid properties in relational database systems.

3
00:00:13,410 --> 00:00:21,560
‫Eventual consistency is another term that was born recently, specifically as a no sequel.

4
00:00:21,600 --> 00:00:24,330
‫Databases started to emerge.

5
00:00:24,540 --> 00:00:30,810
‫And this video, we will discuss and talk about the different kind of consistencies and we will explain

6
00:00:30,810 --> 00:00:39,060
‫what eventual consistency mean, how both actually relational databases and also equal databases suffer

7
00:00:39,270 --> 00:00:41,130
‫from this eventual consistency.

8
00:00:41,130 --> 00:00:44,370
‫And this is something that is not very clear out there.

9
00:00:44,700 --> 00:00:49,080
‫So a lot of people think that eventual consistency is something for just not equal.

10
00:00:49,380 --> 00:00:49,730
‫Right.

11
00:00:49,740 --> 00:00:51,010
‫But that's not entirely correct.

12
00:00:51,180 --> 00:00:55,140
‫If you want to find out how that is the case, stay tuned.

13
00:00:55,150 --> 00:00:55,910
‫This agenda.

14
00:00:56,040 --> 00:00:57,450
‫Here's all I want to talk about today.

15
00:00:58,440 --> 00:01:02,640
‫In order to talk about eventual consistency, I really need to talk about consistency.

16
00:01:02,850 --> 00:01:06,690
‫And I have two types of consistency here to discuss.

17
00:01:06,690 --> 00:01:12,510
‫And it's very critical to disambiguate this these two types of consistencies.

18
00:01:13,350 --> 00:01:15,530
‫And then we're going to talk about eventual consistency.

19
00:01:15,540 --> 00:01:24,960
‫But let's let's learn about consistency first so you can have consistency in your data or consistency

20
00:01:24,960 --> 00:01:26,250
‫during the reads.

21
00:01:26,640 --> 00:01:31,540
‫And these are two separate concepts that we really need to understand.

22
00:01:31,560 --> 00:01:35,820
‫I'm going to talk about each of them now, consistency in the data specifically.

23
00:01:35,820 --> 00:01:37,230
‫Let's take an example here.

24
00:01:37,530 --> 00:01:46,020
‫And it emerges when you have multiple reviews and representation of your data, especially with multiple

25
00:01:46,020 --> 00:01:54,030
‫tables, four and Keys joins, that kind of consistency emerges when you have these multiple collections

26
00:01:54,030 --> 00:02:00,500
‫of data that represents kind of the same unit when you have essentially a normalized view of your data.

27
00:02:00,540 --> 00:02:01,430
‫That's setting an example.

28
00:02:01,430 --> 00:02:02,790
‫Let's say this is Instagram.

29
00:02:02,790 --> 00:02:04,470
‫I have a table called pictures.

30
00:02:04,620 --> 00:02:10,470
‫I have an idea of the picture, the blob and the total number of likes that this picture received.

31
00:02:10,650 --> 00:02:16,890
‫And there is another picture, another table that actually list all the users who liked what pictures

32
00:02:17,430 --> 00:02:17,900
‫make sense.

33
00:02:18,090 --> 00:02:24,990
‫So theoretically, these two views present the same thing, which is a picture and users.

34
00:02:25,000 --> 00:02:25,320
‫Right.

35
00:02:25,620 --> 00:02:31,080
‫But in reality, those two better be consistent.

36
00:02:31,080 --> 00:02:31,410
‫Right.

37
00:02:31,420 --> 00:02:37,870
‫That means if I picture one got to likes them and if I go to the other table, there must be two records.

38
00:02:38,400 --> 00:02:42,480
‫So that's a consistent view of the data itself.

39
00:02:43,290 --> 00:02:49,470
‫And there are a lot of things that ensure this kind of consistency, especially when you're updating

40
00:02:49,470 --> 00:02:50,950
‫multiple things and data.

41
00:02:51,130 --> 00:02:58,740
‫Relational databases are great for this, especially with that tomasetti and isolation and make sure

42
00:02:58,740 --> 00:03:05,550
‫that you're touching as much as stable as possible and is going to ensure that consistency for you in

43
00:03:05,550 --> 00:03:06,160
‫the data.

44
00:03:06,210 --> 00:03:10,080
‫Let's talk more about that consistency in the data as defined by the user.

45
00:03:10,110 --> 00:03:17,400
‫I split those two views into two multiple tables, pictures and the user like balance sheets and the

46
00:03:17,400 --> 00:03:18,990
‫sales, all the stuff.

47
00:03:18,990 --> 00:03:24,300
‫You split it up and you normalize your database the way you want, but is essentially defined by you

48
00:03:24,300 --> 00:03:25,690
‫as a as a user.

49
00:03:25,690 --> 00:03:28,410
‫And the user is essentially whoever designed the database.

50
00:03:28,950 --> 00:03:29,280
‫Right.

51
00:03:30,420 --> 00:03:31,830
‫You get a differential integrities.

52
00:03:31,830 --> 00:03:38,880
‫You get the foreign keys that represent those tables, you delete one if you delete the picture.

53
00:03:39,060 --> 00:03:39,480
‫Right.

54
00:03:39,480 --> 00:03:43,530
‫And the back example, if I deleted this picture, all those records will go away.

55
00:03:43,530 --> 00:03:43,910
‫Right.

56
00:03:44,730 --> 00:03:49,350
‫If you have Cascade's set on your foreign keys and all these things that ensure your consistency in

57
00:03:49,350 --> 00:03:57,390
‫your data and that view, the simple view, narrow view, get almost at and isolation are two properties

58
00:03:57,390 --> 00:04:02,730
‫of the database relational database that ensures, if you think about it is consistent.

59
00:04:02,730 --> 00:04:07,020
‫And we talked about this, but essential items, atomizers like all or one.

60
00:04:07,020 --> 00:04:12,660
‫If you have a transaction with multiple queries touching multiple tables, all of those should fail.

61
00:04:12,900 --> 00:04:13,250
‫Right?

62
00:04:13,260 --> 00:04:19,230
‫If one of them fail and if all of them succeeds, that gets committed n equal databases.

63
00:04:19,230 --> 00:04:24,930
‫Most of them do not have that at Tomasetti on different views.

64
00:04:25,260 --> 00:04:28,800
‫They have a Tomasetti on a different set of collection.

65
00:04:28,800 --> 00:04:31,560
‫If you're updating a collection, that's all you get.

66
00:04:31,770 --> 00:04:35,940
‫If you're touching other stuff, you cannot really ensure that the material, that isolation is the

67
00:04:35,940 --> 00:04:42,810
‫ability is like a fireman and flight transaction can changes to other stuff being seen by me, like

68
00:04:43,110 --> 00:04:48,990
‫of other transactions are executing transactions or changing.

69
00:04:48,990 --> 00:04:51,270
‫Can I see these changes in the same time?

70
00:04:51,480 --> 00:04:56,280
‫And that obviously leads to inconsistent reads, inconsistent results.

71
00:04:56,850 --> 00:04:59,950
‫We talked about that and the other video as well, different finizio.

72
00:05:00,750 --> 00:05:05,860
‫Repeatable, read and noncommitted and all that stuff serialisation.

73
00:05:05,910 --> 00:05:10,220
‫Let's talk about the second type, the read, the consistency.

74
00:05:10,260 --> 00:05:18,920
‫If I have a database here and I say, hey, database update this field, set it to field to value X,

75
00:05:18,930 --> 00:05:19,400
‫OK?

76
00:05:20,220 --> 00:05:26,340
‫And then if I do that, that value will be updated X and consistency and read is nothing.

77
00:05:26,340 --> 00:05:31,910
‫But if a transaction now comes and try to read the value, it better get that new value.

78
00:05:32,340 --> 00:05:34,240
‫That's what consistency in reads me.

79
00:05:34,320 --> 00:05:37,040
‫Now we would say, Hussein, what are you talking about?

80
00:05:37,050 --> 00:05:38,130
‫Of course that makes sense.

81
00:05:38,160 --> 00:05:43,830
‫Yea, if I updated that value of course the new transaction will pick it up.

82
00:05:44,070 --> 00:05:44,940
‫What are you talking about.

83
00:05:44,970 --> 00:05:45,230
‫Right.

84
00:05:45,240 --> 00:05:53,070
‫This type of consistency, relational databases and no SQL databases suffer from this.

85
00:05:53,250 --> 00:05:53,520
‫Right.

86
00:05:54,270 --> 00:05:58,080
‫We cannot guarantee this if we have one database.

87
00:05:58,620 --> 00:06:00,880
‫Life is dandy, right.

88
00:06:01,020 --> 00:06:04,050
‫If you have one server, everything is nice and easy.

89
00:06:04,770 --> 00:06:08,100
‫Relational database is the best if you have one single server.

90
00:06:08,110 --> 00:06:11,010
‫But that's in reality, you never have one server.

91
00:06:11,020 --> 00:06:16,680
‫If you have like a million user, you need to scale lots of wreathes, lots of updates.

92
00:06:16,680 --> 00:06:20,700
‫You're going to add caches, you're going to add nodes, follower nodes.

93
00:06:20,700 --> 00:06:24,870
‫You're going to become you have a one leader node and one multiple follower nodes.

94
00:06:24,870 --> 00:06:33,120
‫And and those follower nodes will take on your knees and you will have one reader or leader, right.

95
00:06:33,120 --> 00:06:33,570
‫Or node.

96
00:06:33,570 --> 00:06:33,840
‫Right.

97
00:06:34,080 --> 00:06:38,730
‫Let's take an example and talk about this eventual consistency concept.

98
00:06:38,730 --> 00:06:39,020
‫Right.

99
00:06:39,030 --> 00:06:40,360
‫In reads, essentially.

100
00:06:40,500 --> 00:06:50,430
‫OK, so now let's say I have this master node or the leader node and then you have to follow or nodes

101
00:06:50,430 --> 00:06:50,730
‫here.

102
00:06:50,730 --> 00:06:56,460
‫OK, that is essentially just getting whatever the master node or the leader nugget's, it will just

103
00:06:56,790 --> 00:06:59,730
‫they follow the values and will get propagated.

104
00:06:59,730 --> 00:07:02,190
‫Those values will be propagated to those follower nuts.

105
00:07:02,790 --> 00:07:10,500
‫And we point the readers to this database so we can offload this huge number of these million users

106
00:07:10,500 --> 00:07:16,680
‫to these databases, put them behind bars or something, and then just offload these huge number of

107
00:07:16,680 --> 00:07:16,950
‫rates.

108
00:07:17,170 --> 00:07:18,310
‫OK, sounds good.

109
00:07:19,050 --> 00:07:22,030
‫Let's say I want to update Z, the values.

110
00:07:22,080 --> 00:07:23,910
‫Now, this is a consistent view.

111
00:07:23,920 --> 00:07:26,690
‫All of these databases are these right.

112
00:07:27,000 --> 00:07:27,940
‫Have a value of Z.

113
00:07:28,260 --> 00:07:30,480
‫I'm going to update it X.

114
00:07:31,230 --> 00:07:32,110
‫Right, OK.

115
00:07:32,160 --> 00:07:33,090
‫So sweet.

116
00:07:33,750 --> 00:07:37,740
‫My leader node now have a value of X, but guess what?

117
00:07:37,740 --> 00:07:43,910
‫At the same time some read someone started to read that value but they got what they got Z.

118
00:07:44,730 --> 00:07:48,140
‫So now this system is inconsistent to me.

119
00:07:48,150 --> 00:07:48,430
‫Right.

120
00:07:49,020 --> 00:07:49,950
‫It's not consistent.

121
00:07:51,220 --> 00:07:57,350
‫Despite that being relational database, this is a postscript database, right?

122
00:07:57,370 --> 00:08:00,060
‫Three politicus instances, it's not consistent.

123
00:08:00,370 --> 00:08:02,230
‫It is eventually consistent.

124
00:08:02,230 --> 00:08:03,440
‫And we're going to talk about that.

125
00:08:03,820 --> 00:08:05,890
‫So we read that we got an old value.

126
00:08:06,100 --> 00:08:07,450
‫We just broke our rule.

127
00:08:07,660 --> 00:08:13,130
‫But we said when I write something and I another transaction, read it, I better get the latest value.

128
00:08:13,360 --> 00:08:14,290
‫It did not.

129
00:08:14,980 --> 00:08:18,640
‫And that is why we are inconsistent here.

130
00:08:18,640 --> 00:08:24,790
‫In this case, this poor slob got an old value that maybe that's OK.

131
00:08:25,000 --> 00:08:28,300
‫But we're just saying now with time.

132
00:08:29,520 --> 00:08:34,150
‫X or the leader, no, we'll stop pushing the new value to the fellow or not.

133
00:08:34,350 --> 00:08:40,440
‫This guy will push the new value now and consider new reads, will start reading the new value.

134
00:08:40,620 --> 00:08:44,340
‫So that's what eventually consist of consistent systems.

135
00:08:44,610 --> 00:08:49,490
‫And this is this is a problem that is in both nonsexual, equal and relational.

136
00:08:49,500 --> 00:08:55,060
‫So eventual consistency is not something for no SQL databases, guys.

137
00:08:55,190 --> 00:08:58,260
‫OK, so we need to really clarify that at first.

138
00:08:58,440 --> 00:09:00,540
‫What do you mean when you say consistency?

139
00:09:00,540 --> 00:09:00,840
‫Right.

140
00:09:00,860 --> 00:09:02,610
‫What do you mean by a consistent system?

141
00:09:02,670 --> 00:09:06,900
‫Are you talking about the read or are you talking about the actual value of the data?

142
00:09:06,900 --> 00:09:08,940
‫Is the consistency from the data itself?

143
00:09:09,160 --> 00:09:12,530
‫Are many different tables because that's great.

144
00:09:12,540 --> 00:09:18,090
‫Yeah, that update might touch seven tables in an atomic manner, in an isolated manner.

145
00:09:18,570 --> 00:09:23,250
‫And that view is consistent in this database.

146
00:09:23,520 --> 00:09:32,280
‫But the whole system to the user, it is not consistent because you introduce those new hobs, the same

147
00:09:32,280 --> 00:09:37,890
‫thing with if you introduce in a cache like a Redish or Memcache D, right the moment you introduce

148
00:09:37,890 --> 00:09:38,490
‫a cash.

149
00:09:39,480 --> 00:09:46,650
‫You're inconsistent whenever you have a cash, you're inconsistent because you will remain inconsistent

150
00:09:46,650 --> 00:09:47,970
‫unless you update the cash.

151
00:09:48,840 --> 00:09:55,110
‫Once your data has two places you're inconsistent, you will become eventually consistent, which is

152
00:09:55,260 --> 00:09:58,140
‫this is this is just a marketing term to me, right?

153
00:09:58,530 --> 00:09:59,100
‫Yeah, of course.

154
00:09:59,100 --> 00:10:00,420
‫It's eventual consistency.

155
00:10:00,430 --> 00:10:01,260
‫And this gets yeah.

156
00:10:01,500 --> 00:10:03,150
‫Eventually these values will get it.

157
00:10:03,150 --> 00:10:07,650
‫But it's up to you now as a user, as a software engineer.

158
00:10:07,950 --> 00:10:09,160
‫Can you tolerate that?

159
00:10:09,180 --> 00:10:10,130
‫Is that OK?

160
00:10:10,620 --> 00:10:11,310
‫Is that OK?

161
00:10:11,320 --> 00:10:21,510
‫If the user read a value and they got 7000, 7000 likes instead of seven thousand eleven likes.

162
00:10:21,630 --> 00:10:24,750
‫Right on Kylie Jenner's latest picture.

163
00:10:24,940 --> 00:10:27,120
‫OK, maybe not.

164
00:10:27,300 --> 00:10:28,230
‫I don't care.

165
00:10:28,450 --> 00:10:28,850
‫Right.

166
00:10:28,930 --> 00:10:39,360
‫I don't care if that egg picture got three million and 20 hundred thousand views that even a number

167
00:10:39,570 --> 00:10:43,500
‫right on a picture versus the second person.

168
00:10:43,500 --> 00:10:48,570
‫Actually God like I don't know, another an extra fifty thousand likes extra.

169
00:10:49,050 --> 00:10:49,950
‫It doesn't matter.

170
00:10:50,460 --> 00:10:52,020
‫Sometimes it doesn't matter.

171
00:10:52,110 --> 00:10:53,250
‫Sometimes it does matter.

172
00:10:53,250 --> 00:10:55,050
‫If I updated my balance.

173
00:10:55,050 --> 00:10:59,850
‫Right, if I deposited thousand dollar I better see that thousand dollar.

174
00:10:59,940 --> 00:11:00,440
‫Right.

175
00:11:00,660 --> 00:11:02,910
‫If I withdrew some.

176
00:11:04,080 --> 00:11:07,020
‫If I say if I withdrew some money.

177
00:11:07,270 --> 00:11:07,650
‫Right.

178
00:11:07,860 --> 00:11:14,250
‫And let's say at the same time I did double withdrawal, double spend and I end up with two thousand

179
00:11:14,250 --> 00:11:14,640
‫dollars.

180
00:11:14,640 --> 00:11:17,580
‫Why I have only one thousand dollars in my account.

181
00:11:17,760 --> 00:11:23,850
‫That's an inconsistent it's good for me because I was able to check the bank and draw two thousand dollars

182
00:11:23,850 --> 00:11:25,380
‫while I have only one thousand.

183
00:11:25,680 --> 00:11:26,040
‫Right.

184
00:11:26,280 --> 00:11:27,900
‫Because of this inconsistency.

185
00:11:28,770 --> 00:11:30,210
‫And that's something bad.

186
00:11:30,450 --> 00:11:30,770
‫Right.

187
00:11:30,870 --> 00:11:32,460
‫So that's eventual consistency and.

188
00:11:32,790 --> 00:11:38,100
‫All right, let's talk more about the consistency and if a transaction committed a change, well, a

189
00:11:38,100 --> 00:11:40,040
‫new transaction immediately could see that change.

190
00:11:40,110 --> 00:11:42,990
‫That's what that's what a consistency in reads mean.

191
00:11:43,590 --> 00:11:45,570
‫It's a different than inconsistency in data.

192
00:11:46,110 --> 00:11:49,530
‫I don't know if there are times I made those two terms up.

193
00:11:49,530 --> 00:11:52,560
‫OK, this is the real thing.

194
00:11:52,560 --> 00:11:55,450
‫I don't know if they have an actual scientific term.

195
00:11:55,470 --> 00:11:55,790
‫Right.

196
00:11:56,040 --> 00:11:58,350
‫But what what do you think about it?

197
00:11:58,350 --> 00:12:00,300
‫That's the only thing I can think about it.

198
00:12:00,570 --> 00:12:03,390
‫There's a data consistency and there is a real consistency.

199
00:12:03,540 --> 00:12:10,260
‫And you have to clarify that the difference is it's a problem in both equal, not equal and relational.

200
00:12:10,260 --> 00:12:10,590
‫Right.

201
00:12:10,710 --> 00:12:19,260
‫As long as you want to scale horizontally and reduce gadgety right weather with no equal databases.

202
00:12:20,660 --> 00:12:23,180
‫And if you have Scharpling, that's a different story.

203
00:12:23,190 --> 00:12:25,050
‫We're not going to talk about Sharding in this video.

204
00:12:25,050 --> 00:12:25,320
‫Right.

205
00:12:25,980 --> 00:12:27,570
‫But that's in a nutshell.

206
00:12:27,840 --> 00:12:34,050
‫The moment you introduce gashing or you try to scale horizontally by adding some follower nodes, you

207
00:12:34,050 --> 00:12:34,950
‫are inconsistent.

208
00:12:34,950 --> 00:12:36,740
‫That's eventual consistency and show.

209
00:12:37,590 --> 00:12:39,210
‫So summary, what did we talk about?

210
00:12:39,210 --> 00:12:42,720
‫We talked about consistency, talked about the different two types of consistency.

211
00:12:42,750 --> 00:12:43,010
‫Right.

212
00:12:43,230 --> 00:12:45,210
‫We talk about consistency in the data.

213
00:12:45,210 --> 00:12:48,180
‫We talked about consistency in REDESCRIBE.

214
00:12:48,480 --> 00:12:51,610
‫We talked about the how those two differ.

215
00:12:51,610 --> 00:12:51,840
‫Right.

216
00:12:51,840 --> 00:13:00,270
‫Consistency in the data is guaranteed by this property that's called a Thomas City and isolation and

217
00:13:00,270 --> 00:13:01,770
‫even durability, if you think about it.

218
00:13:01,770 --> 00:13:02,130
‫Right.

219
00:13:02,190 --> 00:13:06,090
‫So it's like if you if I commit and I read again, a better be there.

220
00:13:06,090 --> 00:13:06,390
‫Right?

221
00:13:06,630 --> 00:13:10,650
‫If it's not there, then it's not durable, then it's not consistent if you think about it.

222
00:13:10,860 --> 00:13:15,450
‫And eventual consistency is the ability to for the reads only write.

223
00:13:15,540 --> 00:13:17,190
‫This is a point I forgot to mention.

224
00:13:17,190 --> 00:13:21,330
‫If you screw up your atomic transaction, you have seven tables.

225
00:13:21,330 --> 00:13:22,950
‫They have to stay consistent together.

226
00:13:22,950 --> 00:13:23,190
‫Right.

227
00:13:23,370 --> 00:13:26,580
‫And you updated three and you got blue screen of death.

228
00:13:26,580 --> 00:13:29,820
‫There is no eventual consistency coming out of that dude.

229
00:13:29,820 --> 00:13:31,950
‫You just screwed you corrupted your database.

230
00:13:31,950 --> 00:13:34,290
‫There is no overall consistency in that.

231
00:13:34,350 --> 00:13:38,820
‫If you do not have a Tomasetti, you do not have eventual consistent.

232
00:13:38,820 --> 00:13:40,680
‫You do not have consistency at all.

233
00:13:40,950 --> 00:13:46,380
‫Consistency in Reed is different than consistency in the data.

234
00:13:46,420 --> 00:13:52,500
‫It is a I sure I'm going to commit that eventually that the follower, not if it's offline, I'm going

235
00:13:52,500 --> 00:13:54,930
‫to come online and is going to pick up the new data.

236
00:13:54,960 --> 00:13:55,530
‫That's OK.

237
00:13:55,530 --> 00:14:02,700
‫We know that's going to be because we know that this site, we guaranteed that consistency at that leader

238
00:14:02,700 --> 00:14:03,090
‫node.

239
00:14:03,090 --> 00:14:08,460
‫But the moment you screw up, you don't have isolation, you don't have proper automaticity, you don't

240
00:14:08,460 --> 00:14:09,510
‫have durability.

241
00:14:09,990 --> 00:14:13,730
‫No eventual consistency can actually help you here, my friend.

242
00:14:13,740 --> 00:14:14,070
‫All right.

243
00:14:14,070 --> 00:14:16,760
‫So you just your data is done, OK?

244
00:14:16,800 --> 00:14:20,160
‫You have corrupted inconsistent data.

245
00:14:20,160 --> 00:14:27,060
‫If you have inconsistent data, there is no point of doing an inconsistent read because your view will

246
00:14:27,060 --> 00:14:29,910
‫always be inconsistent no matter how long you waited.

247
00:14:29,910 --> 00:14:31,260
‫And I'm going to see you in the next one.

248
00:14:31,410 --> 00:14:32,990
‫You guys stay awesome.