1
00:00:06,570 --> 00:00:08,210
- Now let's look at another pattern

2
00:00:08,210 --> 00:00:10,380
that can leverage a buffer channel,

3
00:00:10,380 --> 00:00:11,740
and this is the drop pattern.

4
00:00:11,740 --> 00:00:14,420
Drop patterns are very,
very powerful patterns.

5
00:00:14,420 --> 00:00:17,610
Again, helping us reduce back pressure

6
00:00:17,610 --> 00:00:18,790
when things are going bad.

7
00:00:18,790 --> 00:00:21,730
They can help us actually
identify when things are going bad

8
00:00:21,730 --> 00:00:23,240
and reduce back pressure.

9
00:00:23,240 --> 00:00:24,840
Good example of a drop pattern could be

10
00:00:24,840 --> 00:00:27,260
if you were writing a DNS server.

11
00:00:27,260 --> 00:00:30,540
What are the chances of that
DNS server getting attacked?

12
00:00:30,540 --> 00:00:32,070
Nah, it's never gonna happen, right?

13
00:00:32,070 --> 00:00:34,830
Yeah, it's gonna get
attacked all day long.

14
00:00:34,830 --> 00:00:37,410
The whole idea of that DNS server attack

15
00:00:37,410 --> 00:00:40,130
is to flood the server
with so many requests

16
00:00:40,130 --> 00:00:43,860
that it drowns itself trying
to process everything.

17
00:00:43,860 --> 00:00:44,743
So you can't.

18
00:00:44,743 --> 00:00:47,040
What the drop pattern tries to identify

19
00:00:47,040 --> 00:00:50,000
is what our capacity is, right?

20
00:00:50,000 --> 00:00:52,690
What is the maximum number
of pending anything,

21
00:00:52,690 --> 00:00:56,010
requests, tasks, that we can take in

22
00:00:56,010 --> 00:00:58,050
before we have to say no.

23
00:00:58,050 --> 00:00:59,410
Look, it's easy to say yes.

24
00:00:59,410 --> 00:01:01,480
You gotta learn how to say no in life.

25
00:01:01,480 --> 00:01:02,840
And at some point you have to know

26
00:01:02,840 --> 00:01:06,217
what is your maximum capacity,
and then just say no.

27
00:01:06,217 --> 00:01:08,840
And a drop pattern, we
say, I'm sorry I can't

28
00:01:08,840 --> 00:01:10,060
handle your requests.

29
00:01:10,060 --> 00:01:12,820
I'm at capacity, I'm not
going to go down for you.

30
00:01:12,820 --> 00:01:15,180
It's going to take integration
tests and load testing,

31
00:01:15,180 --> 00:01:17,600
usually, to figure out
what your capacity is.

32
00:01:17,600 --> 00:01:20,410
And it might also be based
on how much memory you have,

33
00:01:20,410 --> 00:01:22,870
and your CPU capacity, could be dynamic

34
00:01:22,870 --> 00:01:24,460
depending on the system
that you're running on.

35
00:01:24,460 --> 00:01:26,610
But drop patterns are very, very powerful.

36
00:01:26,610 --> 00:01:29,490
They help us identify failures quickly,

37
00:01:29,490 --> 00:01:31,210
they help us stop the bleeding.

38
00:01:31,210 --> 00:01:33,270
And then, they help us move forward again,

39
00:01:33,270 --> 00:01:34,890
when the bleeding has been,

40
00:01:34,890 --> 00:01:37,383
or when that wound has been healed.

41
00:01:38,350 --> 00:01:40,510
Let's take a look at a basic drop pattern.

42
00:01:40,510 --> 00:01:42,850
So, here we are, got a constant of five.

43
00:01:42,850 --> 00:01:44,140
And this time what I'm going to do,

44
00:01:44,140 --> 00:01:46,840
is make a buffered channel of five.

45
00:01:46,840 --> 00:01:48,740
This buffered channel
of five is our capacity.

46
00:01:48,740 --> 00:01:51,300
What we're saying is once
we have at least five

47
00:01:51,300 --> 00:01:55,870
pending tasks waiting in our buffer here,

48
00:01:55,870 --> 00:01:56,770
we're at capacity.

49
00:01:56,770 --> 00:01:58,450
We're not going to go to six.

50
00:01:58,450 --> 00:01:59,700
At that point, we're just going to drop

51
00:01:59,700 --> 00:02:00,620
the work on the floor.

52
00:02:00,620 --> 00:02:01,570
We're not going to take it.

53
00:02:01,570 --> 00:02:03,770
Taking anymore is too much risk.

54
00:02:03,770 --> 00:02:06,400
Now, if you look at on line 194,

55
00:02:06,400 --> 00:02:08,370
here we are again in our main,

56
00:02:08,370 --> 00:02:11,670
we've created our buffer channel of five.

57
00:02:11,670 --> 00:02:12,900
That's our buffer channel of five.

58
00:02:12,900 --> 00:02:14,730
That's our capacity.

59
00:02:14,730 --> 00:02:17,370
We go ahead and we launch a Go routine.

60
00:02:17,370 --> 00:02:19,890
Now, this could have easily been

61
00:02:19,890 --> 00:02:21,740
a pool of Go routines, right?

62
00:02:21,740 --> 00:02:23,940
But, and we're just
keeping the code simple,

63
00:02:24,840 --> 00:02:27,173
understand this could be
one or many Go routines.

64
00:02:27,173 --> 00:02:29,170
And there we are, again,
on the four range.

65
00:02:29,170 --> 00:02:32,330
We are receiving on line 195,

66
00:02:32,330 --> 00:02:36,370
receiving from this buffer.

67
00:02:36,370 --> 00:02:38,250
In other words, what
we're going to be doing

68
00:02:38,250 --> 00:02:39,750
on this one Go routine,

69
00:02:39,750 --> 00:02:42,270
is we're going to be
in our receive, right?

70
00:02:42,270 --> 00:02:44,810
We're going to be in our channel receive.

71
00:02:44,810 --> 00:02:47,770
Where the idea here
is, here's our channel,

72
00:02:47,770 --> 00:02:48,660
receive that.

73
00:02:48,660 --> 00:02:51,570
As soon as data comes in to the buffer,

74
00:02:51,570 --> 00:02:55,120
then we want the corresponding,

75
00:02:55,120 --> 00:02:56,100
right, it's a receive.

76
00:02:56,100 --> 00:02:57,510
So, once data comes into the buffer,

77
00:02:57,510 --> 00:02:59,950
the send happens before the receive,

78
00:02:59,950 --> 00:03:01,240
but once we see it,

79
00:03:01,240 --> 00:03:03,260
then we're going to want to pull it out.

80
00:03:03,260 --> 00:03:04,980
More data comes in, we're
going to pull it out.

81
00:03:04,980 --> 00:03:09,060
But this Go routine's only
operating on one task at a time.

82
00:03:09,060 --> 00:03:11,910
So, once we receive it, we process it.

83
00:03:11,910 --> 00:03:14,050
We come back, we pull any more data.

84
00:03:14,050 --> 00:03:16,620
If there isn't any data,
then we block on the channel

85
00:03:16,620 --> 00:03:17,740
receive, waiting, right?

86
00:03:17,740 --> 00:03:18,630
That's the floor range.

87
00:03:18,630 --> 00:03:20,350
Eventually, we close the channel

88
00:03:20,350 --> 00:03:22,950
and the floor range terminates.

89
00:03:22,950 --> 00:03:25,700
So, here's the idea,
maybe we're reading some

90
00:03:25,700 --> 00:03:27,480
network device, right?

91
00:03:27,480 --> 00:03:30,790
Let's do that right there
on line 201, for a second.

92
00:03:30,790 --> 00:03:33,560
Maybe what we're doing now
that we've set this up,

93
00:03:33,560 --> 00:03:38,560
is we're here, and you
know, maybe we're reading.

94
00:03:38,750 --> 00:03:40,560
We're reading, sorry reading,

95
00:03:40,560 --> 00:03:42,210
some sort of network.

96
00:03:42,210 --> 00:03:45,240
And as we pull data out of the network,

97
00:03:45,240 --> 00:03:47,640
we just start moving it, right?

98
00:03:47,640 --> 00:03:51,580
We send it into our buffer.

99
00:03:51,580 --> 00:03:53,220
But once this hits five,

100
00:03:53,220 --> 00:03:54,710
we know a couple things.

101
00:03:54,710 --> 00:03:57,480
Once this hits five we
can't do this anymore.

102
00:03:57,480 --> 00:03:59,297
Now, this data has to go from here,

103
00:03:59,297 --> 00:04:00,710
and we have to drop it.

104
00:04:00,710 --> 00:04:02,120
We can't add it, we drop it.

105
00:04:02,120 --> 00:04:03,420
We're not going to block.

106
00:04:03,420 --> 00:04:06,210
At the same time, it could
mean that this Go routine

107
00:04:06,210 --> 00:04:07,490
isn't running fast enough.

108
00:04:07,490 --> 00:04:10,700
It could mean that this Go
routine has a problem right now.

109
00:04:10,700 --> 00:04:12,880
It's not coming back into the receive.

110
00:04:12,880 --> 00:04:14,520
And so, the health of our system

111
00:04:14,520 --> 00:04:16,410
is measured by our capacity.

112
00:04:16,410 --> 00:04:18,640
If this is working fast enough,

113
00:04:18,640 --> 00:04:20,790
then this buffer never gets full.

114
00:04:20,790 --> 00:04:24,499
But if something bad happens,
and the buffer gets full,

115
00:04:24,499 --> 00:04:27,850
we no longer block, we don't
take blocking latencies,

116
00:04:27,850 --> 00:04:28,980
we drop.

117
00:04:28,980 --> 00:04:31,410
Now, in order for this to
work, we got to be able

118
00:04:31,410 --> 00:04:35,970
to identify when we're full,
without fully blocking.

119
00:04:35,970 --> 00:04:39,050
And I want you to see the use
of the select statement here.

120
00:04:39,050 --> 00:04:42,170
So, I'm in my loop here, where
I'm going to be simulating

121
00:04:42,170 --> 00:04:44,590
20 network reads of data,

122
00:04:44,590 --> 00:04:46,280
and I'm in a select.

123
00:04:46,280 --> 00:04:49,980
Now, what's powerful about
the select statement,

124
00:04:49,980 --> 00:04:52,460
is it allows a single Go routine,

125
00:04:52,460 --> 00:04:55,070
to handle multiple channel operations,

126
00:04:55,070 --> 00:04:56,740
whether they're sends or receives,

127
00:04:56,740 --> 00:04:58,900
at exactly the same time.

128
00:04:58,900 --> 00:05:01,343
So you can create event loops here.

129
00:05:01,343 --> 00:05:03,670
This is also how we're
going to do cancellation

130
00:05:03,670 --> 00:05:04,730
and deadlines,

131
00:05:04,730 --> 00:05:07,270
and a drop pattern is very
much like a cancellation.

132
00:05:07,270 --> 00:05:08,470
So, look at what we do here.

133
00:05:08,470 --> 00:05:11,170
I've got the select, and
we've got our first case,

134
00:05:11,170 --> 00:05:12,870
which is the channel send.

135
00:05:12,870 --> 00:05:17,000
Again, the idea is we've read
some data off the network

136
00:05:17,000 --> 00:05:20,830
and on line 203 we're
trying to perform this send.

137
00:05:20,830 --> 00:05:23,140
We're trying to perform the send.

138
00:05:23,140 --> 00:05:26,140
Now, if we can perform the send,

139
00:05:26,140 --> 00:05:29,130
if we can perform this send, guess what?

140
00:05:29,130 --> 00:05:31,840
The data gets in the buffer, life is good,

141
00:05:31,840 --> 00:05:34,120
we go back to 201 in the top of the loop

142
00:05:34,120 --> 00:05:35,620
and we get the next piece of data.

143
00:05:35,620 --> 00:05:37,750
We try to perform the send again.

144
00:05:37,750 --> 00:05:40,220
If the send is not going to block,

145
00:05:40,220 --> 00:05:43,150
because there's room in
the buffer, brilliant.

146
00:05:43,150 --> 00:05:45,840
But what if that send is going to block

147
00:05:45,840 --> 00:05:47,470
because we are at capacity.

148
00:05:47,470 --> 00:05:49,220
Remember, if all five,

149
00:05:49,220 --> 00:05:51,460
if there's five pending tasks in here,

150
00:05:51,460 --> 00:05:52,940
then it's going to block.

151
00:05:52,940 --> 00:05:55,700
We don't want that latency cost, right?

152
00:05:55,700 --> 00:05:57,553
So, that's where the default comes in.

153
00:05:57,553 --> 00:05:59,610
What the default says is,

154
00:05:59,610 --> 00:06:03,020
if the send is going to block, guess what?

155
00:06:03,020 --> 00:06:06,020
Don't block, move on.

156
00:06:06,020 --> 00:06:07,530
Move on.

157
00:06:07,530 --> 00:06:09,000
Move on.

158
00:06:09,000 --> 00:06:10,330
And we're, basically, now going to decide

159
00:06:10,330 --> 00:06:11,570
what we're going to do with this data

160
00:06:11,570 --> 00:06:12,550
we read off the network.

161
00:06:12,550 --> 00:06:14,070
We're going to somehow drop it.

162
00:06:14,070 --> 00:06:15,550
Maybe send back a 500,

163
00:06:15,550 --> 00:06:17,160
maybe send back that we couldn't do it.

164
00:06:17,160 --> 00:06:18,900
We're not going to take latency costs.

165
00:06:18,900 --> 00:06:21,020
We're not going to create back pressure

166
00:06:21,020 --> 00:06:22,240
against this channel.

167
00:06:22,240 --> 00:06:25,480
Either we can do it, or we can't do it.

168
00:06:25,480 --> 00:06:28,440
And when we can do it,
brilliant, let's get it done.

169
00:06:28,440 --> 00:06:31,750
When we can't do it, it's
a really strong indication

170
00:06:31,750 --> 00:06:33,670
that we have a problem in our server.

171
00:06:33,670 --> 00:06:37,020
So, drop patterns are
very, very important.

172
00:06:37,020 --> 00:06:39,110
They're very clean ways of identifying

173
00:06:39,110 --> 00:06:40,520
when we're at capacity.

174
00:06:40,520 --> 00:06:42,360
When we're having potential problems,

175
00:06:42,360 --> 00:06:44,668
they help reduce back pressure.

176
00:06:44,668 --> 00:06:48,170
Because this isn't necessarily
time out reduction,

177
00:06:48,170 --> 00:06:50,530
it's literally, capacity reduction.

178
00:06:50,530 --> 00:06:52,770
And again, we're using
the buffered channel

179
00:06:52,770 --> 00:06:54,820
to help us identify when there's failure.

180
00:06:54,820 --> 00:06:57,350
And, eventually, when this buffer begins

181
00:06:57,350 --> 00:06:59,020
to be processed again,

182
00:06:59,020 --> 00:07:01,270
then we know that life is good again.

183
00:07:01,270 --> 00:07:04,090
So drop patterns are very,
very, very powerful patterns.

184
00:07:04,090 --> 00:07:06,980
And another, kind of,
core high-level pattern

185
00:07:06,980 --> 00:07:09,680
along with the pooling,
along with the fan outs,

186
00:07:09,680 --> 00:07:12,270
that you'll be using to
handle different types

187
00:07:12,270 --> 00:07:14,283
of orchestration in your software.