1
00:00:01,300 --> 00:00:05,710
In this video I want to show you three more possible solutions that will not work to actually solve

2
00:00:05,710 --> 00:00:07,150
this concurrency stuff.

3
00:00:07,150 --> 00:00:12,280
Now for some people listening to this video these concurrency discussions might be a bit confusing or

4
00:00:12,280 --> 00:00:13,750
really vague or boring.

5
00:00:13,750 --> 00:00:18,100
So if you do not want to hear anything else about concurrency pauses video right now and go on to the

6
00:00:18,100 --> 00:00:18,910
next video.

7
00:00:18,910 --> 00:00:22,900
Otherwise stick around and I'll show you three more possible solutions you might think of that are not

8
00:00:22,900 --> 00:00:24,490
going to quite work out.

9
00:00:24,580 --> 00:00:25,230
So if you're still here.

10
00:00:25,270 --> 00:00:26,820
Let's get to it.

11
00:00:26,920 --> 00:00:31,570
Here's another possible solution that is not going to quite work in this possible solution.

12
00:00:31,570 --> 00:00:37,740
We're going to say that we once again have multiple instances of the Account Service A and B.

13
00:00:37,910 --> 00:00:42,190
We're also going to say that A and B have some shared state between the two of them.

14
00:00:42,230 --> 00:00:45,640
So this might be some shared Reddit server might be a shared database.

15
00:00:45,680 --> 00:00:48,200
It might be direct network connections whatever it is.

16
00:00:48,200 --> 00:00:51,920
It is some shared piece of information in the shared state.

17
00:00:51,920 --> 00:00:57,170
We're going to record the sequence number of every processed event that ever gets processed by A and

18
00:00:57,170 --> 00:01:03,530
B then whenever a or b receives an event to process it will look into the shared state and make sure

19
00:01:03,530 --> 00:01:07,160
that the previous sequence number has already been processed.

20
00:01:07,190 --> 00:01:09,560
So let's walk through what this would really look like.

21
00:01:09,680 --> 00:01:11,710
So we're going to imagine that we get no one.

22
00:01:11,720 --> 00:01:15,610
It goes over to service a service label immediately process this event.

23
00:01:15,620 --> 00:01:18,280
So it's going to deposit 70 dollars.

24
00:01:18,320 --> 00:01:21,530
It will then take that sequence number and put it into the shared store.

25
00:01:21,530 --> 00:01:25,600
Like so next up sequence number two.

26
00:01:25,620 --> 00:01:26,460
That's deposit.

27
00:01:26,460 --> 00:01:32,010
Well imagine that goes over to B B is going to then look into this data store and see if the previous

28
00:01:32,010 --> 00:01:33,060
event sequence number.

29
00:01:33,060 --> 00:01:36,390
So in this case no one has already been processed.

30
00:01:36,390 --> 00:01:39,390
No one has been processed because it is inside the state of store.

31
00:01:39,480 --> 00:01:43,790
And that means that now service B can successfully or at least try to process.

32
00:01:43,800 --> 00:01:44,790
Number two.

33
00:01:44,790 --> 00:01:46,920
So in this case deposit 40 dollars.

34
00:01:46,920 --> 00:01:51,810
No problem will then take that sequence number and put in the shared data store.

35
00:01:52,070 --> 00:01:59,210
And then finally withdrawal goes over to a h checks to see if Number Two has been processed because

36
00:01:59,210 --> 00:02:02,410
three minus one is too yet looks like two is already in there.

37
00:02:02,450 --> 00:02:07,220
So we can successfully withdraw the hundred dollars right away.

38
00:02:07,260 --> 00:02:12,660
So this is a good solution in that it makes sure that we're only ever going to process any event exactly

39
00:02:12,660 --> 00:02:17,670
one time and we're always going to make sure that we only process any or as we all of our events in

40
00:02:17,670 --> 00:02:18,800
the correct order.

41
00:02:18,960 --> 00:02:20,880
That's the benefit to the solution.

42
00:02:20,880 --> 00:02:26,640
The downside is that it requires due process all the events that comes into the services in essentially

43
00:02:26,670 --> 00:02:31,400
a sequential fashion which has a really big performance penalty.

44
00:02:31,410 --> 00:02:38,880
Think about what would happen here if we had actually two accounts instead of just one.

45
00:02:38,970 --> 00:02:42,780
Let's say that we've got an account for user a.

46
00:02:42,840 --> 00:02:47,980
That starts off at zero and user fee that starts off at zero.

47
00:02:47,980 --> 00:02:55,020
So now this first event right here might be a deposit for user a that next one might be a deposit for

48
00:02:55,020 --> 00:02:55,710
user B.

49
00:02:56,430 --> 00:03:04,500
So let's now imagine this goes into a and this goes into B now at this point B.

50
00:03:04,500 --> 00:03:09,600
Down here is gonna take a look at this shared store and I can say has no one been processed yet when

51
00:03:09,620 --> 00:03:10,220
this scenario.

52
00:03:10,230 --> 00:03:11,650
No we're still waiting.

53
00:03:11,940 --> 00:03:16,980
And let's imagine that this event fails processing for whatever reasoning maybe service a does not have

54
00:03:16,980 --> 00:03:22,980
a collection or a connection to the file store or maybe it's just laggy or who knows what's going on.

55
00:03:23,010 --> 00:03:27,210
So you have to essentially wait for this deposit or this event right here to time out over the span

56
00:03:27,210 --> 00:03:31,710
of 30 seconds and eventually be reissued by the NAT server.

57
00:03:31,830 --> 00:03:37,320
And while we are waiting for that 30 seconds deposit for account B right here is going to be held up

58
00:03:37,710 --> 00:03:44,010
even though this account right here account for user B is completely unrelated from user a.

59
00:03:44,850 --> 00:03:50,520
So in other words we are always limited globally for all of our different accounts to only processing

60
00:03:50,520 --> 00:03:56,550
exactly one update at a time which is clearly not a great thing it means every single update that we

61
00:03:56,550 --> 00:03:57,920
want to make inside our application.

62
00:03:58,020 --> 00:04:02,940
Only one update and that means that we are going to be severely constrained in how many or how much

63
00:04:02,940 --> 00:04:07,080
processing or how many updates we can run at any given point in time.

64
00:04:07,170 --> 00:04:10,700
So the solution looks good but it doesn't quite work.

65
00:04:10,770 --> 00:04:15,040
Let's try to take some elements from the solution though and move it forward to another attempt.

66
00:04:16,990 --> 00:04:17,260
OK.

67
00:04:17,290 --> 00:04:21,190
So now in this attempt we're going to try to directly solve that issue we ran into you with the last

68
00:04:21,190 --> 00:04:21,780
one.

69
00:04:21,820 --> 00:04:27,370
So in this case we're going to say that we're going to track exactly which event or watch user each

70
00:04:27,370 --> 00:04:29,890
event is intended to be processed for.

71
00:04:29,890 --> 00:04:36,750
So in this case we're going to say that user gem it's sequence number one he's trying to deposit 70

72
00:04:36,750 --> 00:04:38,070
dollars.

73
00:04:38,070 --> 00:04:45,180
So this is going to go off to service say we're going to try to process for user Jim a deposit of 70.

74
00:04:45,200 --> 00:04:46,600
So it's going to make that change.

75
00:04:46,670 --> 00:04:52,690
And then inside the shared data store we will say that for user Jim we have processed his first event.

76
00:04:52,940 --> 00:05:01,200
They'll store it like so so then the next event to come in is maybe sequence number one for user Mary.

77
00:05:01,280 --> 00:05:07,110
And she is trying to deposit 40 dollars so because this is the first event for user Mary we'll just

78
00:05:07,110 --> 00:05:09,290
go ahead and merely deposit that 40.

79
00:05:09,330 --> 00:05:16,310
Everything looks good then inside the shared data store we'll also record.

80
00:05:16,430 --> 00:05:22,560
We've got Mary's first event then user Jim is going to have 2 and 3.

81
00:05:22,580 --> 00:05:28,580
We have processed both those and shared them inside this data store.

82
00:05:28,590 --> 00:05:29,580
So this is very similar.

83
00:05:29,600 --> 00:05:32,460
But now each user has their own sequence numbers.

84
00:05:32,460 --> 00:05:33,330
How does this solve the issue.

85
00:05:33,330 --> 00:05:34,340
We just ran into.

86
00:05:34,340 --> 00:05:39,020
Well let's think through it really quickly I'm going to undo the diagram.

87
00:05:39,090 --> 00:05:44,010
So we're back to event number one coming into service right here.

88
00:05:44,010 --> 00:05:51,570
Let's say that we go ahead and process this event and we deposit seventy dollars into user Jim's account.

89
00:05:51,590 --> 00:05:56,800
So now we're going to have this first event for Mary go over to service B.

90
00:05:57,140 --> 00:06:01,910
And simultaneously we'll imagine that this deposit for Jim goes into service.

91
00:06:02,150 --> 00:06:06,320
Now once again let's say that user Mary's deposit right here is having some big issues.

92
00:06:06,470 --> 00:06:11,460
Maybe there is an error in processing maybe he cannot connect to the file storage whatever it is.

93
00:06:11,540 --> 00:06:15,200
We cannot process this event with the previous solution we just looked at.

94
00:06:15,200 --> 00:06:20,390
That would have held up Jim's deposit as well but because we are accounting sequence numbers separately

95
00:06:20,390 --> 00:06:25,490
for different users this service day is going to take a look inside of our shared sequence numbers database

96
00:06:25,510 --> 00:06:29,450
that's going to say okay for user Jim where'd you process Jim's first event.

97
00:06:29,450 --> 00:06:31,300
Well this has an event number of 2.

98
00:06:31,310 --> 00:06:34,100
So we are definitely safe in processing Jim's second event.

99
00:06:34,550 --> 00:06:36,610
Let's go ahead and deposit 40 dollars.

100
00:06:36,650 --> 00:06:44,310
Now Jim is up to one hundred and ten then Jim can issue is withdrawal will once again look in.

101
00:06:44,310 --> 00:06:44,690
Okay.

102
00:06:44,970 --> 00:06:48,110
User Jim we've done his first and second event now in its third.

103
00:06:48,270 --> 00:06:49,700
Let's go and process it.

104
00:06:49,810 --> 00:06:52,440
Let's withdraw a hundred dollars we're now down to 10.

105
00:06:52,470 --> 00:06:53,830
Everything looks good.

106
00:06:53,830 --> 00:06:59,850
And in this entire process we might still be waiting on user Mary's first deposit.

107
00:06:59,850 --> 00:07:05,190
So with this kind of scenario we can make sure that one user does not affect another user.

108
00:07:05,190 --> 00:07:10,050
Now we're talking about users here but of course this kind of applies to any kind of resource we can

109
00:07:10,050 --> 00:07:14,580
essentially say that any requests is going to modify some type of resource we're going to put all the

110
00:07:14,580 --> 00:07:20,690
events related to one kind of owner of that resource into its own kind of sequence pool.

111
00:07:20,700 --> 00:07:27,530
Now this is a great solution right here but there's a little issue with the actual implementation we're

112
00:07:27,530 --> 00:07:32,210
really talking about giving every user or every kind of owner of something here it's own personal little

113
00:07:32,210 --> 00:07:38,090
bit of sequence it turns out that with Nat streaming server to get a restarted sequence we have to create

114
00:07:38,120 --> 00:07:40,380
a totally different channel.

115
00:07:40,520 --> 00:07:45,560
So if we want to do something like this we would have to have two channels reserved just for Jim and

116
00:07:45,560 --> 00:07:49,460
we might give them a name like account deposit Jim an account withdrawal.

117
00:07:49,460 --> 00:07:57,560
Jim we then have to come up with two identical looking channels dedicated just to Mary.

118
00:07:57,640 --> 00:08:01,350
So deposit for Mary and withdrawal from Mary as well.

119
00:08:01,370 --> 00:08:05,710
That's the only way out of the box with Nat streaming server that we can get those restarted sequence

120
00:08:05,710 --> 00:08:06,830
numbers.

121
00:08:06,910 --> 00:08:11,100
This definitely sounds like well hey whatever let's just create more channels.

122
00:08:11,230 --> 00:08:15,790
Unfortunately that streaming server there's a decent amount of overhead in adding more channels to be

123
00:08:15,790 --> 00:08:21,430
processed out of the box Nat string server is only going to allow you to have 1000 channels by default

124
00:08:21,790 --> 00:08:26,800
we can increase that number of course or decrease it if we want to but as we create more channels there's

125
00:08:26,800 --> 00:08:30,780
more processing overhead with each one that we create.

126
00:08:30,880 --> 00:08:36,130
So we are not going to be able to create a separate set of channels for every single user or every type

127
00:08:36,130 --> 00:08:40,010
of resource that needs its own sequence numbering.

128
00:08:40,030 --> 00:08:44,530
So this is a solution that definitely looks good but it's not going to work with Nat streaming and as

129
00:08:44,530 --> 00:08:49,270
a matter of fact it turns out that this idea of having these different pools or these different channels

130
00:08:49,270 --> 00:08:54,370
where each one has its own little sequence it turns out that creating these different sequences with

131
00:08:54,430 --> 00:08:57,610
any event plus ends up being a lot of processing overhead.

132
00:08:57,730 --> 00:09:02,080
So you're going to see some resources online that advocate this kind of approach but unfortunately again

133
00:09:02,350 --> 00:09:07,450
you're going to have a kind of tough time finding an event boss implementation that will allow each

134
00:09:07,450 --> 00:09:10,700
of these to get their own sequence numbers.

135
00:09:10,830 --> 00:09:17,320
So all right let's take a look at one more possible solution so in this possible solution we're going

136
00:09:17,320 --> 00:09:20,640
to see something that's very similar to the one we just looked at what we're going to work around that

137
00:09:20,640 --> 00:09:25,830
limitation of not being able to assign each of our different users or kind of owners of resource their

138
00:09:25,830 --> 00:09:28,150
own separate sequence numbers.

139
00:09:28,170 --> 00:09:31,560
Now the other thing I want to remind you is that I've been showing all these diagrams with the sequence

140
00:09:31,560 --> 00:09:34,180
number being known somehow to the publisher.

141
00:09:34,260 --> 00:09:37,880
In reality the sequence number is not automatically known to the publisher.

142
00:09:37,890 --> 00:09:42,420
Instead our publisher is going to publish some event that's going to go over to the Natsumi server and

143
00:09:42,450 --> 00:09:45,180
only then does it get assigned a sequence number.

144
00:09:45,330 --> 00:09:51,820
And then after that it will be sent on to whatever listeners there are so in this approach we're going

145
00:09:51,820 --> 00:09:57,580
to start off with this list of events once again and we're going to somehow store each of these events

146
00:09:57,820 --> 00:09:59,150
at the publisher.

147
00:09:59,200 --> 00:10:03,490
So when I say I started the event I literally mean the publishers can have some kind of database where

148
00:10:03,490 --> 00:10:09,830
it is going to list all the different events that it has dispatched over time as it dispatches each

149
00:10:09,830 --> 00:10:11,040
of these events.

150
00:10:11,120 --> 00:10:16,400
We're going to hope or just kind of pray that after it gets sent over to that streaming server Nats

151
00:10:16,410 --> 00:10:21,110
will send back a message and say Here's the sequence number of the event that you just dispatched.

152
00:10:21,140 --> 00:10:22,330
So we throw this thing over.

153
00:10:22,430 --> 00:10:26,900
It would be assigned number one and then we would hope that that streaming server will send that number

154
00:10:26,900 --> 00:10:28,910
one back over to our publisher.

155
00:10:28,910 --> 00:10:35,030
So then this publisher can say okay I dispatch an event it had sequence of number one and that was for

156
00:10:35,030 --> 00:10:35,750
user Jim.

157
00:10:35,750 --> 00:10:37,310
And here's what the actual event was

158
00:10:40,240 --> 00:10:42,170
done in this event.

159
00:10:42,260 --> 00:10:45,380
We'll go on to our services and then be processed.

160
00:10:45,650 --> 00:10:50,480
So we'll say in this case okay I was going to posit many dollars into Jim's account but here's Jim right

161
00:10:50,480 --> 00:10:50,940
here.

162
00:10:50,960 --> 00:10:56,750
Deposit 70 and then simultaneously we're going to make sure that service a right here stores the I.D.

163
00:10:57,080 --> 00:11:00,370
of the sequence number or the sequence of the sequence number of the event.

164
00:11:00,380 --> 00:11:08,240
It just processed so it's store number one to say I just processed number one.

165
00:11:08,320 --> 00:11:11,870
So now the publisher would move on to say number two.

166
00:11:11,980 --> 00:11:13,510
Same thing would occur here.

167
00:11:13,510 --> 00:11:15,380
We're going to dispatch that.

168
00:11:15,640 --> 00:11:19,930
This thing will be assigned at number two because remember we can only get sequence numbers for the

169
00:11:19,960 --> 00:11:27,220
overall events that go into a channel so hopefully once again this number two would be sent back over

170
00:11:27,220 --> 00:11:28,170
to our publisher.

171
00:11:28,330 --> 00:11:31,420
And it would save that number to write their.

172
00:11:31,560 --> 00:11:34,260
This would go on to our service.

173
00:11:34,260 --> 00:11:35,820
We would take a look at Mary.

174
00:11:35,820 --> 00:11:39,760
We would deposit 40 dollars into her account and we would say the last idea that we process for the

175
00:11:39,760 --> 00:11:42,620
thing was number two.

176
00:11:42,620 --> 00:11:46,060
So now we move on to user Jim with user Jim.

177
00:11:46,070 --> 00:11:50,600
We know that we are making a modification to the user Jim and we know that the last time we modified

178
00:11:50,600 --> 00:11:54,650
user Jim was right here because we are storing all these events.

179
00:11:54,830 --> 00:11:59,660
So we know that the last time we modified user Jim we had an event with a sequence number of number

180
00:11:59,660 --> 00:12:02,720
one they put in the number one right there.

181
00:12:02,720 --> 00:12:08,990
We would then throw this event once again over to Nats this thing would be assigned a sequence number

182
00:12:08,990 --> 00:12:09,760
of number three.

183
00:12:09,770 --> 00:12:15,030
We've had a record that back over here and then we would send this event on to one of our listeners.

184
00:12:15,070 --> 00:12:19,920
And now here's the critical part when service a takes a look at this.

185
00:12:19,990 --> 00:12:25,300
And it goes to process it it would take a look at what the last I.D. was or the last sequence number

186
00:12:25,600 --> 00:12:31,070
40 event that modified user Jim service they could then look inside the database and make sure that

187
00:12:31,070 --> 00:12:36,320
the most recent I.D. for Jim was number one as long as that number one right there and number one right

188
00:12:36,320 --> 00:12:40,920
there are equal to each other than service say we'll say Okay I will process this event.

189
00:12:41,030 --> 00:12:47,420
I will deposit 40 dollars taking us up to 110 and then record this things I.D. or sequence number as

190
00:12:47,420 --> 00:12:54,220
the last sequence processed and now finally we'll move on so for user Jim right here.

191
00:12:54,240 --> 00:12:55,470
We know this is about Jim.

192
00:12:55,470 --> 00:13:01,280
So once again we take a look at the most recent event that they had a sequence number of three.

193
00:13:01,750 --> 00:13:09,690
So we put that in right there send this off to Nats this would be given sequence number four and once

194
00:13:09,690 --> 00:13:12,780
again this would go on to our listener.

195
00:13:12,810 --> 00:13:14,710
Now we're making a modification to user Jim.

196
00:13:14,720 --> 00:13:18,360
We'd make sure the last I.D. we processed our last sequence was number three.

197
00:13:18,380 --> 00:13:19,390
Yep it was.

198
00:13:19,400 --> 00:13:21,430
So let's go ahead and apply this update.

199
00:13:21,500 --> 00:13:23,300
We're going to withdraw a hundred dollars.

200
00:13:23,300 --> 00:13:29,360
We're now down to 10 and we'll update that sequence idea right there too for and that's the whole idea.

201
00:13:31,000 --> 00:13:36,610
So we're going to essentially the keys here are to make sure that the publisher understands the ideas

202
00:13:36,610 --> 00:13:42,430
or the sequence is applied to every given event that's going to store those and we'll know which ideas

203
00:13:42,430 --> 00:13:44,530
or which sequences applied to which user.

204
00:13:44,710 --> 00:13:50,440
Then whenever it dispatches a event tied to that user in the future it will also attach the sequence

205
00:13:50,440 --> 00:13:53,150
for the previous event that modified it.

206
00:13:53,160 --> 00:13:59,480
So now with this whole scenario Imagine what would happen if we simultaneously kind of rewind here a

207
00:13:59,480 --> 00:14:07,110
little bit when we undo a little bit and let's say that we go back to the scenario where we've got a

208
00:14:07,110 --> 00:14:19,740
deposit for Jim and simultaneously a withdrawal as well like so so in this case the deposit would have

209
00:14:19,830 --> 00:14:21,800
a sequence of three and then four like.

210
00:14:21,790 --> 00:14:26,960
So the most recent event for the withdrawal would have been the three.

211
00:14:26,960 --> 00:14:27,140
Yeah.

212
00:14:27,150 --> 00:14:28,140
There we go.

213
00:14:28,140 --> 00:14:33,150
So let's imagine what would happen if we accidentally tried to process the withdrawal before the deposit.

214
00:14:33,150 --> 00:14:38,790
In this case service B would take a look at the idea the last processed one it was number one but this

215
00:14:38,790 --> 00:14:43,920
thing this event says that the last event or the last sequence number concern with this event was number

216
00:14:43,920 --> 00:14:44,760
three.

217
00:14:44,760 --> 00:14:45,920
1 in 3 are not equal.

218
00:14:45,960 --> 00:14:49,170
So service B would refuse to process this event right here.

219
00:14:49,170 --> 00:14:50,520
It would say you know what.

220
00:14:50,520 --> 00:14:53,860
Number one as ers me number three has not yet been processed.

221
00:14:53,880 --> 00:14:57,600
We're going to assume that's going to come in very shortly but until it does I'm going to refuse to

222
00:14:57,600 --> 00:14:59,910
process this event entirely.

223
00:14:59,910 --> 00:15:02,810
So then we were just essentially sit around and wait.

224
00:15:03,030 --> 00:15:07,410
Eventually if this thing times out and get sent back or Jeanette's No problem we're just gonna keep

225
00:15:07,410 --> 00:15:12,210
waiting around until eventually sequence number three gets processed one sequence number three gets

226
00:15:12,210 --> 00:15:12,930
processed.

227
00:15:13,050 --> 00:15:18,010
The one is equal to the last I.D. processed right here so we'll go ahead and process that we're up to

228
00:15:18,010 --> 00:15:18,620
the 110.

229
00:15:18,660 --> 00:15:23,850
And now finally we can handle this event right here.

230
00:15:23,940 --> 00:15:27,500
OK so this one admittedly is pretty darn confusing.

231
00:15:27,530 --> 00:15:28,660
Where does this work.

232
00:15:28,660 --> 00:15:34,950
Well yes and no not quite the whole problem here you might have noticed when I drag this thing over.

233
00:15:34,960 --> 00:15:38,890
I had said that the publisher doesn't actually know the sequence number and so we were gonna kind of

234
00:15:38,890 --> 00:15:41,170
hope that Nat sent back the sequence number.

235
00:15:41,170 --> 00:15:45,310
That does not actually occur when we send an event off to be published by not streaming.

236
00:15:45,310 --> 00:15:47,020
It's kind of a one way operation.

237
00:15:47,020 --> 00:15:51,220
We don't really get the ability to somehow reach out to Nats and say hey for that event we posted a

238
00:15:51,220 --> 00:15:51,670
bit ago.

239
00:15:51,670 --> 00:15:53,340
What was the sequence number on it.

240
00:15:53,350 --> 00:15:58,420
It's something that gets published or known only by Nats and we have a pretty tough time to reach in

241
00:15:58,450 --> 00:16:01,170
and figure out what that sequence number actually was.

242
00:16:01,180 --> 00:16:05,970
So we can't really somehow reach back and say oh yeah this thing was given a sequence number of one.

243
00:16:06,010 --> 00:16:12,820
So any now any future event tied to a user of Jim in this case would have been this one right here.

244
00:16:12,920 --> 00:16:14,920
The last sequence should have been one.

245
00:16:14,960 --> 00:16:16,710
That's the part that we can't really solve.

246
00:16:16,760 --> 00:16:21,790
We can't really store what the last sequence number was for Jim nonetheless.

247
00:16:21,800 --> 00:16:25,910
This does seem like it's getting even closer even though we are being held up by a little technical

248
00:16:25,910 --> 00:16:27,520
limitation here.

249
00:16:27,600 --> 00:16:27,820
OK.

250
00:16:27,860 --> 00:16:30,680
So that's it for these three additional possible solutions.

251
00:16:30,680 --> 00:16:33,120
Once again I apologize for the duration of this video.

252
00:16:33,140 --> 00:16:37,190
This was an optional video and I just want to throw out these other possible solutions.

253
00:16:37,200 --> 00:16:37,430
OK.

254
00:16:37,610 --> 00:16:38,850
So quick pause right here.

255
00:16:38,870 --> 00:16:42,020
We'll take a look at how we're going to actually solve this in the next video.