1
00:00:00,830 --> 00:00:04,400
In the last couple of videos we've looked at a bunch of diagrams that laid out a bunch of different

2
00:00:04,400 --> 00:00:06,400
solutions to this concurrency stuff.

3
00:00:06,400 --> 00:00:07,380
It's now in this video.

4
00:00:07,400 --> 00:00:10,670
We're gonna try to come up with some kind of solution to this problem.

5
00:00:10,910 --> 00:00:15,860
Can tell you right now this is going to be a long video but I've kind of planned it with a ton of diagrams

6
00:00:15,860 --> 00:00:18,870
so hopefully it should capture your interest for some amount of time.

7
00:00:18,890 --> 00:00:22,580
Let me first begin by telling you what we're really going to do in this video and how we're gonna solve

8
00:00:22,580 --> 00:00:24,280
this concurrency stuff.

9
00:00:24,280 --> 00:00:25,630
So I got to make a claim here.

10
00:00:25,790 --> 00:00:31,010
I'm going to say that this entire accounting application that we're trying to fix up with this concurrency

11
00:00:31,010 --> 00:00:33,740
stuff is just poorly designed.

12
00:00:33,740 --> 00:00:37,460
And in all the solutions we've looked at so far we've been trying to figure out how we could somehow

13
00:00:37,460 --> 00:00:41,720
use nets to save this concurrency problem or somehow fix it.

14
00:00:41,780 --> 00:00:45,860
In other words we've been looking at Nats and trying to imagine how we could use those sequence numbers

15
00:00:45,890 --> 00:00:49,110
and so on to somehow properly order these events.

16
00:00:49,300 --> 00:00:54,530
I'm going to make a big claim here and say that that was actually a really poor approach.

17
00:00:54,590 --> 00:00:57,440
It's the system itself that is poorly designed.

18
00:00:57,500 --> 00:01:02,480
In other words we can't really use Nats to somehow save this application or this accounting stuff.

19
00:01:02,480 --> 00:01:07,080
We need to figure out how to redesign the application itself.

20
00:01:07,110 --> 00:01:10,310
We need to figure out how to redesign the services inside of it.

21
00:01:10,560 --> 00:01:15,870
And if we provide a better designed to the system I think you're going to see that a better solution

22
00:01:15,870 --> 00:01:20,610
for this concurrency stuff is actually going to present itself without even worrying about any of the

23
00:01:20,610 --> 00:01:23,590
internal features of Nats whatsoever.

24
00:01:23,610 --> 00:01:28,560
So long story short what we're really going to do in this video is try to redesign this accounting service

25
00:01:29,070 --> 00:01:33,870
and then at the very end after we redesign the entire thing we're going to very quickly see that there's

26
00:01:33,870 --> 00:01:40,590
actually a pretty easy and straightforward way to solve all this concurrency problem so let's get to

27
00:01:40,590 --> 00:01:40,790
it.

28
00:01:40,800 --> 00:01:45,120
We're going to first try to redesign this accounting application to get started.

29
00:01:45,120 --> 00:01:48,720
We're going to look at something that looks very unrelated right now.

30
00:01:48,720 --> 00:01:50,160
I know this looks really unrelated.

31
00:01:50,160 --> 00:01:53,910
I want to think back in time to that blog post application.

32
00:01:53,910 --> 00:02:00,650
We worked on in the first section of this course so in that application we had a request handler that

33
00:02:00,660 --> 00:02:04,850
would allow us to create a new post so we'd make a request to create a post that would go to the postal

34
00:02:04,850 --> 00:02:08,190
service the Postal Service would save that post internally.

35
00:02:08,190 --> 00:02:10,980
It was in memory but we'll call it a database whatever.

36
00:02:10,980 --> 00:02:14,540
We then created an event to describe that post being created.

37
00:02:14,580 --> 00:02:20,220
We sent that off to a event boss that we had built and that event eventually flowed onto our query service.

38
00:02:20,220 --> 00:02:24,720
And the goal of that query service was to take a lot of these different events and build up a complete

39
00:02:24,720 --> 00:02:30,050
picture of all the different posts and comments we had inside of our app the comment service was very

40
00:02:30,050 --> 00:02:30,670
similar.

41
00:02:30,710 --> 00:02:32,490
We made a request of the common service.

42
00:02:32,720 --> 00:02:38,860
We saved it to some database we emitted an event and then it flowed onto the query service.

43
00:02:39,020 --> 00:02:42,520
So I now want to take this diagram right here and to simplify it a little bit.

44
00:02:42,560 --> 00:02:47,710
Apply some easier to understand terminology in some critical locations.

45
00:02:47,720 --> 00:02:47,960
OK.

46
00:02:47,990 --> 00:02:50,960
So very similar diagram I've just simplified it a pretty good amount.

47
00:02:51,020 --> 00:02:55,620
I also removed the comments related stuff so here's what was really going on.

48
00:02:55,700 --> 00:03:00,390
We made a request to create post that went to the postal service and that was a service that was 100

49
00:03:00,410 --> 00:03:03,600
percent responsible for what a post was.

50
00:03:03,710 --> 00:03:08,990
It knew exactly all the attributes that a post had and was the canonical source to define what a post

51
00:03:08,990 --> 00:03:13,340
was we stored that information side of a database.

52
00:03:13,340 --> 00:03:17,490
And we then emitted some event describing the fact that the post was just created.

53
00:03:17,690 --> 00:03:21,620
We didn't actually send it over to Nats that went to our customer event boss but essentially that eventually

54
00:03:21,620 --> 00:03:27,670
got related over to the query service where that event was consumed not going to even further simplify

55
00:03:27,670 --> 00:03:28,430
this diagram.

56
00:03:28,450 --> 00:03:30,580
I got to move the idea of post entirely.

57
00:03:30,610 --> 00:03:36,880
I'm going to move the idea of query service and just put on some more generic terminology.

58
00:03:37,020 --> 00:03:42,310
It's now in here we've got some really generic terms that's going to describe what we're going to try

59
00:03:42,310 --> 00:03:47,040
to do over on the accounting service or that account counting application as well.

60
00:03:47,100 --> 00:03:50,750
So we really want to have in general in a micros services application.

61
00:03:50,820 --> 00:03:56,520
We want to somehow make a request to modify a resource that request should always go to some service

62
00:03:56,700 --> 00:04:01,240
that completely owns that resource in this case we're imagining it's a resource called X Y Z.

63
00:04:02,010 --> 00:04:08,400
So that service is going to own the definition of what x y z is when receives a request to create update

64
00:04:08,460 --> 00:04:10,220
or delete this resource.

65
00:04:10,230 --> 00:04:15,120
Well those changes will be made in some accompanying database.

66
00:04:15,150 --> 00:04:20,280
Well then you met an event describing the fact that the x y z resource has changed and that event can

67
00:04:20,280 --> 00:04:24,180
flow to all the other services inside of our app that need to modify its data.

68
00:04:24,180 --> 00:04:30,970
Based upon this event so I now want to take this kind of flow right here and apply it to the accounting

69
00:04:31,000 --> 00:04:32,340
application.

70
00:04:32,500 --> 00:04:36,940
So when we go back over to the accounting application diagrams we've been working with there's a couple

71
00:04:36,940 --> 00:04:38,970
of things that immediately pop up to me.

72
00:04:39,100 --> 00:04:45,210
We've been putting tremendous focus on the nat string server and the service that somehow listening

73
00:04:45,210 --> 00:04:46,830
to events coming out of it.

74
00:04:47,010 --> 00:04:52,890
And so respectively that's really reference to this part of diagram right here this yellow box and this

75
00:04:53,040 --> 00:04:58,530
gray box down here and our entire design for this accounting application we've been working with has

76
00:04:58,550 --> 00:05:02,070
a 100 percent neglected everything over here.

77
00:05:02,100 --> 00:05:09,600
In other words we have not even remotely begun to think about what this publisher thing really is where

78
00:05:09,600 --> 00:05:10,860
these events are coming from.

79
00:05:10,860 --> 00:05:14,920
And the underlying data that these events correspond to.

80
00:05:15,000 --> 00:05:16,110
So here's what I want to do.

81
00:05:16,230 --> 00:05:21,310
I want to get a better idea of what service is actually managing at these events right here.

82
00:05:21,420 --> 00:05:26,400
And like I said as soon as we start to get a better idea of what these service is that's actually meeting

83
00:05:26,400 --> 00:05:32,920
these events and handling this concurrency stuff is going to get a lot easier so when I look at this

84
00:05:32,920 --> 00:05:38,800
publisher I'm seeing that it's emitting some events kind of concerned with account transactions of sorts

85
00:05:39,190 --> 00:05:45,200
a transaction let's imagine is something that tries to exchange money in or out of an account.

86
00:05:45,220 --> 00:05:50,530
So if we try to follow the same pattern of something like this right here to describe this accounting

87
00:05:50,530 --> 00:05:56,620
application we might end up with something like this right here so down here at the bottom right hand

88
00:05:56,620 --> 00:05:58,300
side we still have an account service.

89
00:05:58,390 --> 00:06:04,150
We still have the Nats event bus but now we've got this entire idea of a service that is somehow going

90
00:06:04,150 --> 00:06:09,970
to receive requests to create a transaction thing a service that's going to record all these transactions

91
00:06:10,330 --> 00:06:14,950
a database for storing them and then anytime someone tries to create a transaction chances are we're

92
00:06:14,950 --> 00:06:19,690
going to emit some kind of event describing the fact that a transaction was just created.

93
00:06:19,690 --> 00:06:24,910
And so these events right here that we're going to emit are essentially used to these events right here

94
00:06:24,910 --> 00:06:28,830
inside this diagram.

95
00:06:28,870 --> 00:06:33,190
Now let's start to think about how we would actually design the service and have some database to store

96
00:06:33,250 --> 00:06:35,410
the transactions that people are trying to create.

97
00:06:35,980 --> 00:06:38,430
So we might end up with something like this right here.

98
00:06:38,470 --> 00:06:43,240
So in this diagram we're imagining that someone's logging onto maybe some banking Web site as some particular

99
00:06:43,240 --> 00:06:49,750
user will imagine that it's a user with an I.D. of C Z Q And then this user on our banking Web site

100
00:06:49,810 --> 00:06:56,080
is going to use the online banking stuff and eventually try to deposit 70 dollars then 40 and then withdraw

101
00:06:56,140 --> 00:06:57,360
100.

102
00:06:57,470 --> 00:07:01,610
Now we really start to follow this pattern of the pattern side this diagram right here.

103
00:07:01,610 --> 00:07:04,010
Imagine what would really go on behind the scenes.

104
00:07:04,010 --> 00:07:10,630
Each of these requests would probably fall off to some transaction service and then from there the transaction

105
00:07:10,630 --> 00:07:16,060
service would want to store those in some kind of database and maybe in this database we would store

106
00:07:16,300 --> 00:07:21,460
the user I.D. who made the transaction or who created it and then it would associate with that would

107
00:07:21,460 --> 00:07:24,940
be a list of all the transactions that they have created over time.

108
00:07:24,940 --> 00:07:30,680
So the first request would maybe create a record like this right here maybe the second request would

109
00:07:30,680 --> 00:07:36,010
it create a record like so and then the third request or withdraw one would create a record like that

110
00:07:36,010 --> 00:07:42,860
right there and then once again if we really follow the pattern laid out in this diagram as we store

111
00:07:42,890 --> 00:07:47,360
all these different records inside this transaction database we'd probably want to also you met some

112
00:07:47,360 --> 00:07:52,180
kind of event describing the fact that we had just emitted or created these transactions.

113
00:07:52,280 --> 00:07:54,370
So it's going to walk through that process as well.

114
00:07:55,260 --> 00:08:00,990
So here's our transaction database transaction service we're going to want to emit some events describing

115
00:08:00,990 --> 00:08:05,490
the fact that these things were just created and maybe send them over to say our customer event boss

116
00:08:05,790 --> 00:08:11,430
or this case let's say we're sending off to the Nats streaming server so I want to imagine what an event

117
00:08:11,430 --> 00:08:14,420
would look like that would describe these things being created.

118
00:08:14,430 --> 00:08:15,860
Well maybe you would look something like this.

119
00:08:15,890 --> 00:08:21,030
Maybe for the first object out there the first transaction we would emit an object or an event with

120
00:08:21,030 --> 00:08:23,700
a type of transaction related

121
00:08:28,110 --> 00:08:33,160
and then inside of here we would probably want to list some information about the transaction that just

122
00:08:33,160 --> 00:08:34,240
been created as well.

123
00:08:34,300 --> 00:08:43,040
So maybe we would say a was a deposit of 70 dollars maybe the transaction itself has an I.D. of K SJ

124
00:08:43,060 --> 00:08:50,530
f I.D. K SJ F and then maybe we also put on say the user's I.D. as well.

125
00:08:50,560 --> 00:09:01,110
So like user I.D. and that is C C Q And then maybe kind of interestingly maybe it would be handy for

126
00:09:01,110 --> 00:09:02,730
some reason I don't know.

127
00:09:02,730 --> 00:09:08,640
Let's just imagine if we also included in this event a description of what this transactions number

128
00:09:08,640 --> 00:09:10,400
was for this user.

129
00:09:10,400 --> 00:09:15,000
So let's say that the very first transaction that the user creates has a number of one and then the

130
00:09:15,000 --> 00:09:18,570
next one has a number of two then a number of three and so on.

131
00:09:18,570 --> 00:09:23,210
So for this first event I would give it a number of one.

132
00:09:23,640 --> 00:09:28,890
So we'll say this is very similar to a sequence number but it's kind of being determined by this database

133
00:09:29,100 --> 00:09:31,620
as opposed to gnats or something like that.

134
00:09:31,630 --> 00:09:37,640
So now we can repeat that process for these other two transactions as well I would create another one.

135
00:09:37,660 --> 00:09:41,270
This one would be a deposit of 40 an idea of 5 J.

136
00:09:41,290 --> 00:09:45,100
Twenty five and a number of two.

137
00:09:45,230 --> 00:09:49,880
And then finally this last one would be a withdrawal

138
00:09:52,920 --> 00:09:53,940
of one hundred.

139
00:09:54,120 --> 00:09:56,430
Maybe we'll give it an idea as well as well.

140
00:09:56,600 --> 00:09:59,500
One Kayo one and this would be at number three.

141
00:09:59,510 --> 00:10:01,000
Like so now.

142
00:10:01,020 --> 00:10:05,520
These are the three events that we can imagine we would throw over to prevent us and we want those to

143
00:10:05,520 --> 00:10:08,590
eventually flow on to any services.

144
00:10:09,420 --> 00:10:15,060
That want to somehow watch for new transactions being created and so in our case that would be the account

145
00:10:15,060 --> 00:10:15,980
service.

146
00:10:16,070 --> 00:10:22,080
So let's now imagine how that account service would really be put together.

147
00:10:22,080 --> 00:10:28,140
So we've once again got our transactions database we've got the Nat string server maybe it has a channel

148
00:10:28,140 --> 00:10:33,570
of transaction created and we can imagine maybe there are two account services listening for events

149
00:10:33,630 --> 00:10:38,760
from that channel and then these account services very similar to the query service we had put together

150
00:10:38,790 --> 00:10:44,190
earlier probably would have some kind of database for it that would take in a list of all these transactions

151
00:10:44,520 --> 00:10:52,380
and then prevent or present or calculate a total sum for each user's account balance I'm going to go

152
00:10:52,380 --> 00:10:57,540
and pull those events we just defined over and we'll imagine what these things would do to process these

153
00:10:57,540 --> 00:11:04,770
events so we can imagine the first event would flow maybe to a right here let's just take the information

154
00:11:04,770 --> 00:11:10,260
out of this event and store it inside this accounts database and here's the part where since we've gone

155
00:11:10,260 --> 00:11:15,000
through this really and have better design and the transaction service you're going to see that these

156
00:11:15,000 --> 00:11:20,700
concurrency issues start to fall away and the current currency issue is going to fall away without having

157
00:11:20,700 --> 00:11:28,510
to rely upon any fancy features of Nats server so we're going to imagine that we start to process this

158
00:11:28,510 --> 00:11:29,830
event right here.

159
00:11:29,970 --> 00:11:30,250
OK.

160
00:11:30,310 --> 00:11:33,940
So let's imagine sidebar accounts database we've got our user sees queue.

161
00:11:33,970 --> 00:11:37,610
That's the person we care about and maybe we've got some other users inside of here as well.

162
00:11:37,620 --> 00:11:41,980
We don't really care about them whatever but they exist inside of here right now.

163
00:11:41,980 --> 00:11:45,320
Susie Q has a balance of presumably zero.

164
00:11:45,500 --> 00:11:49,560
I also want to try to record the last transaction number.

165
00:11:49,580 --> 00:11:54,170
So this last transaction number is going to be essentially the number of the last transaction that we

166
00:11:54,170 --> 00:11:56,600
processed when we first create sees.

167
00:11:56,620 --> 00:12:01,400
Q they'll start off the balance of zero and no last transaction number because we've not processed any

168
00:12:01,400 --> 00:12:05,480
transactions related to them yet so now we'll process the thing okay.

169
00:12:05,490 --> 00:12:11,240
It's deposit 70 so we'll increment by 70 and the number of this transaction was number one.

170
00:12:11,280 --> 00:12:14,490
So put into one like so Okay that is simple enough.

171
00:12:14,610 --> 00:12:24,200
So now we can move on to our next transaction the one of number two so once again we're looking at season

172
00:12:24,230 --> 00:12:31,910
Q It's a deposit of 40 so we'll go up to 110 and now our last transaction that's created was to sell

173
00:12:31,910 --> 00:12:35,880
update lands at last transaction number to do as well.

174
00:12:35,900 --> 00:12:37,580
Now we can move on to the third one.

175
00:12:38,690 --> 00:12:45,020
In this case still the user Susie Q It's a withdrawal of one hundred and a last transaction number is

176
00:12:45,020 --> 00:12:49,310
three in this case or this transaction is number three so we'll update Lancer last transaction number

177
00:12:49,310 --> 00:12:54,330
to three and subtract one hundred off the balance and so we're left with 10 and so in this scenario

178
00:12:54,360 --> 00:12:57,240
it definitely looks like everything still works as expected.

179
00:12:57,270 --> 00:12:57,870
Right.

180
00:12:57,960 --> 00:13:03,360
We still at the end the day end up with some user with the balance and assuming that all these events

181
00:13:03,450 --> 00:13:05,270
flow through the way we expect.

182
00:13:05,280 --> 00:13:07,140
In other words nothing crashes.

183
00:13:07,200 --> 00:13:09,940
We don't get any double issue of an event or anything like that.

184
00:13:09,960 --> 00:13:13,360
It appears that everything works as expected.

185
00:13:13,370 --> 00:13:15,800
So now let's kind of go through this flow again.

186
00:13:15,820 --> 00:13:20,100
Well let's imagine that some of these events are not properly processed.

187
00:13:20,290 --> 00:13:26,140
In other words let's imagine that maybe this first event goes to service a service say in that instant

188
00:13:26,200 --> 00:13:28,150
crashes entirely.

189
00:13:28,150 --> 00:13:32,500
So you and I know based upon what we've done with Nats at this point in time we know that if this thing

190
00:13:32,500 --> 00:13:38,800
crashes and we don't acknowledge this event for 30 seconds eventually Nats will reissue it to someone

191
00:13:38,800 --> 00:13:39,990
else inside this cougar.

192
00:13:40,690 --> 00:13:45,040
But for right now let's just imagine that this thing gets sent into service day and it just does not

193
00:13:45,040 --> 00:13:51,370
get processed right away and it simultaneously maybe event number two right here flows in as well.

194
00:13:51,370 --> 00:13:54,250
So at this point this event not going be processed.

195
00:13:54,250 --> 00:13:56,500
This event will be processed.

196
00:13:56,530 --> 00:13:58,210
Now what would happen.

197
00:13:58,210 --> 00:14:00,710
Well let's add in a new rule here as well.

198
00:14:00,820 --> 00:14:06,070
Let's say that because each of these transaction events right here have a number associated with them

199
00:14:06,460 --> 00:14:08,470
we only want to process this thing.

200
00:14:08,590 --> 00:14:14,920
If the last transaction number for this user stored inside of our database is equal to that number minus

201
00:14:14,920 --> 00:14:19,170
one so once again this thing is crashed.

202
00:14:19,170 --> 00:14:20,510
We're just going to forget about it.

203
00:14:20,550 --> 00:14:21,690
We can't process that right now.

204
00:14:21,690 --> 00:14:23,540
We have to wait 30 seconds.

205
00:14:23,550 --> 00:14:28,740
So then this event comes into service be so service B is going to take a look at its can say okay let's

206
00:14:28,740 --> 00:14:29,280
see.

207
00:14:29,280 --> 00:14:35,240
All right deposit forty four user C.C. Q And it's a number of two that's the number of the transaction.

208
00:14:35,280 --> 00:14:36,990
Now we could set up the service.

209
00:14:36,990 --> 00:14:43,140
So it looks at its database finds user C.C. Q takes a look at the last transaction number in this case

210
00:14:43,410 --> 00:14:51,360
it doesn't have one yet so ideally we want to say take a look at this number of to subtract one and

211
00:14:51,360 --> 00:14:52,810
that's what user sees.

212
00:14:52,830 --> 00:14:57,150
Q Should have for the last transaction number but there's nothing there.

213
00:14:57,180 --> 00:15:02,520
We don't have a one and because of that we're gonna have service be set up to say oh well I guess we

214
00:15:02,520 --> 00:15:05,040
haven't processed transaction one yet.

215
00:15:05,040 --> 00:15:09,690
I'm just going to forget this event I'm going to pass over it entirely.

216
00:15:09,720 --> 00:15:11,160
So what just happened.

217
00:15:11,160 --> 00:15:16,440
Well we failed to process event number one it will be processed or we will attempt to process it process

218
00:15:16,440 --> 00:15:22,890
it again 30 seconds in the future but critically we didn't process that thing before the second one

219
00:15:23,820 --> 00:15:28,710
and that was okay because since we have this number of field on here and we are recording the last transaction

220
00:15:28,710 --> 00:15:34,020
number inside of our current database we knew not to attempt to process this second transaction even

221
00:15:34,020 --> 00:15:38,460
though it was handled by a totally different service than the one that rejected the transaction number

222
00:15:38,460 --> 00:15:44,050
one so we can now imagine that we basically now sit around and we're gonna wait 30 seconds for both

223
00:15:44,050 --> 00:15:51,100
these things to time out and eventually be reissued by Nats so maybe 30 seconds goes by and the Nats

224
00:15:51,140 --> 00:15:53,600
sees that this message never got acknowledged.

225
00:15:53,660 --> 00:15:59,400
So it's then going to take it and pass it on to service be now service B is going to take a look at

226
00:15:59,400 --> 00:16:04,360
this thing it's going say OK deposit seventy to user season Q And it's a number of one.

227
00:16:04,380 --> 00:16:08,820
Okay let's go find Susie Q Oh they don't have a last transaction number well that's okay because this

228
00:16:08,820 --> 00:16:15,910
is the very first transaction so we'll set last transaction to 1 and we'll do our deposit of 70 and

229
00:16:15,910 --> 00:16:16,230
that's it.

230
00:16:16,240 --> 00:16:19,140
We've now successfully process that event.

231
00:16:19,150 --> 00:16:25,120
Now we can imagine that after those 30 seconds now maybe event number two right here finally gets reissued

232
00:16:26,310 --> 00:16:28,710
because it timed out during those 30 seconds.

233
00:16:28,710 --> 00:16:31,020
Now once again we're going to take a look at the thing user season.

234
00:16:31,020 --> 00:16:34,750
Q Last transaction recorded of one.

235
00:16:34,950 --> 00:16:36,720
This one has a number of two.

236
00:16:36,720 --> 00:16:39,710
Okay well two minus one is one fantastic it lines up.

237
00:16:39,720 --> 00:16:41,610
It means we process the first transaction.

238
00:16:41,610 --> 00:16:42,970
We are now on the second one.

239
00:16:43,020 --> 00:16:46,180
Let's process this thing and commit to our database.

240
00:16:46,200 --> 00:16:48,180
So in this case we can deposit 40 dollars.

241
00:16:48,180 --> 00:16:57,110
We're now up to 110 and then as usual we've taken this last event I forgot to update the last transaction

242
00:16:57,110 --> 00:16:58,340
number on that second one.

243
00:16:58,400 --> 00:17:04,670
So we've taken this last event okay user Susie Q last transaction number of two we are on now on number

244
00:17:04,670 --> 00:17:05,150
3.

245
00:17:05,160 --> 00:17:08,600
Yep all lines up Geils go ahead and do that withdrawal of one hundred.

246
00:17:08,840 --> 00:17:15,880
And now we're down to 10 so by adding on this number field right here we have effectively solved all

247
00:17:15,880 --> 00:17:19,250
the different concurrency issues we ran through it in the last couple videos.

248
00:17:19,390 --> 00:17:23,590
This solves the issue where Nats thinks the decline is still alive when it's actually dead.

249
00:17:23,590 --> 00:17:28,150
This solves the issue where maybe one listener might run more quickly than another.

250
00:17:28,180 --> 00:17:32,830
This also solves the issue where a listener can fail to process an events and we have to wait a 30 second

251
00:17:32,830 --> 00:17:35,450
time out for that event to be reissued.

252
00:17:35,470 --> 00:17:39,820
This also solve some issues we ran through in the last video as well where we might have different users

253
00:17:39,820 --> 00:17:43,630
trying to use the database or commit events at the same time.

254
00:17:43,780 --> 00:17:49,230
So if we imagine there are other users or other users creating transactions no problem.

255
00:17:49,390 --> 00:17:52,020
If there's something wrong with this transaction right here.

256
00:17:52,020 --> 00:17:56,820
In other words if we're still on transaction number one and waiting for number two to be committed.

257
00:17:56,920 --> 00:18:03,100
That is not going to prevent user JP for or user Cayenne from creating transactions as well.

258
00:18:03,100 --> 00:18:06,330
It is a per user lockout or again in this case.

259
00:18:06,340 --> 00:18:07,950
We don't want to think about this as per user.

260
00:18:07,950 --> 00:18:11,450
This entire idea can be used with any arbitrary kind of resource.

261
00:18:11,500 --> 00:18:14,560
So this entire idea would have worked with say comments as well.

262
00:18:15,510 --> 00:18:20,540
Now at this point I just want to kind of reflect and say that a lot of this stuff was solved really

263
00:18:20,540 --> 00:18:25,160
by adding on just that no field but we were not able to add on that number field until we started to

264
00:18:25,160 --> 00:18:29,480
really understand the service that all these events were going to come from which in this case was the

265
00:18:29,540 --> 00:18:35,460
transactions database so the transaction service you might merely say Well Steven this is only going

266
00:18:35,460 --> 00:18:40,770
to work if we somehow number each of these transactions and that would have been easy because presumably

267
00:18:40,770 --> 00:18:45,180
we're sticking these transactions in array tied to user C.C. Q That is true.

268
00:18:45,180 --> 00:18:51,210
But as you'll see very shortly we can apply the same methodology to normal records as well so we could

269
00:18:51,210 --> 00:18:55,720
use the same methodology with say our tickets service.

270
00:18:55,750 --> 00:18:58,670
So we just worked on a little bit ago with our ticket service.

271
00:18:58,670 --> 00:19:02,070
We don't have an array to rely upon or anything like that.

272
00:19:02,150 --> 00:19:07,670
But eventually we might want to emit some kind of event like say ticket related until the outside world

273
00:19:07,670 --> 00:19:11,240
that hey we just created a ticket and here's some information about it.

274
00:19:11,270 --> 00:19:16,760
So again we don't really have the benefits or anything like that of working with some numbering of these

275
00:19:16,760 --> 00:19:22,460
tickets because a ticket is one standalone record but there are some ways so we can have a very similar

276
00:19:22,460 --> 00:19:28,040
approach or the similar idea of numbering updates to a ticket over time and then making sure that those

277
00:19:28,220 --> 00:19:33,760
updates are applied sequentially to some other service that relies upon its ok.

278
00:19:33,790 --> 00:19:39,820
So at this point you might be sitting there thinking I'm not quite seeing this stuff don't sweat it

279
00:19:40,210 --> 00:19:44,260
we're going to pause right here we're gonna write out a little bit more code just to work with our little

280
00:19:44,260 --> 00:19:48,400
test example that we've had going on around this accounting stuff we're then going to start to go back

281
00:19:48,400 --> 00:19:53,710
over to events inside of our actual ticketing application and you're going to see how this idea of recording

282
00:19:53,740 --> 00:19:59,050
a last transaction number of sorts is going to work to solve concurrency issues inside of our ticketing

283
00:19:59,110 --> 00:20:01,140
application as well.

284
00:20:01,190 --> 00:20:04,480
So as usual quick pause right here and I'll see you in just a minute.