1
00:00:00,090 --> 00:00:01,560
Welcome to the Architecture 
Corner. 

2
00:00:01,610 --> 00:00:05,020
Today we're diving into the 
fascinating world of load 

3
00:00:05,030 --> 00:00:07,860
testing, but with a really 
crucial twist. 

4
00:00:07,950 --> 00:00:10,390
We're looking at the unique 
challenges, often kind of 

5
00:00:10,400 --> 00:00:13,460
overlooked, that pop up with 
serverless and asynchronous 

6
00:00:13,470 --> 00:00:16,580
applications. 
This whole discussion is sparked

7
00:00:16,590 --> 00:00:19,900
by a really insightful article, 
Load Testing Serverless 

8
00:00:19,910 --> 00:00:23,400
Asynchronous Applications 
Practical Considerations by 

9
00:00:23,410 --> 00:00:27,400
Mario Bittencourt. 
He really unpacks why our usual 

10
00:00:27,410 --> 00:00:30,120
ways of checking if a system is 
ready might well give us a 

11
00:00:30,130 --> 00:00:33,230
dangerously incomplete picture 
when things were distributed and

12
00:00:33,240 --> 00:00:36,170
working asynchronously. 
Yeah, it's interesting how the 

13
00:00:36,180 --> 00:00:39,130
article just immediately grounds
us in today's reality 

14
00:00:39,340 --> 00:00:41,450
applications. 
Now they're rarely just one big 

15
00:00:41,460 --> 00:00:43,310
thing, right? 
That these complex mixes, 

16
00:00:43,320 --> 00:00:45,090
tapestries of connected 
services. 

17
00:00:45,300 --> 00:00:48,270
And our goal always is to figure
out if our system can actually 

18
00:00:48,280 --> 00:00:51,600
handle those demand spikes, you 
know, whether they're planned or

19
00:00:51,610 --> 00:00:54,290
just come out of the blue. 
Load testing, like the article 

20
00:00:54,300 --> 00:00:56,950
says, it pushes us past just 
modeling things theoretically. 

21
00:00:56,960 --> 00:00:58,930
It forces that real world 
validation. 

22
00:00:59,080 --> 00:01:00,650
That's where you find the hidden
problems. 

23
00:01:00,740 --> 00:01:04,569
OK, so let's unpack that. 
The basic idea of load testing 

24
00:01:04,580 --> 00:01:08,040
sounds simple enough. 
You send traffic, you measure 

25
00:01:08,050 --> 00:01:10,590
how it behaves against your 
Slas, your service level 

26
00:01:10,600 --> 00:01:13,100
agreements, those promises we 
make. 

27
00:01:13,320 --> 00:01:16,320
But the article points out some 
pretty big hurdles even before 

28
00:01:16,330 --> 00:01:18,240
we get to the sync or serverless
stuff, right? 

29
00:01:18,250 --> 00:01:19,430
Oh, absolutely. 
Yeah. 

30
00:01:19,440 --> 00:01:22,110
A huge question right off the 
bat is how do you even simulate 

31
00:01:22,120 --> 00:01:25,030
production accurately? 
You need a whole separate setup 

32
00:01:25,040 --> 00:01:27,880
that's identical. 
That's a massive job, even using

33
00:01:27,890 --> 00:01:29,950
infrastructure as code to 
automate things. 

34
00:01:30,170 --> 00:01:32,080
And then there's the data 
dependency problem. 

35
00:01:32,090 --> 00:01:35,940
Simulating real traffic often 
means you need real existing 

36
00:01:35,950 --> 00:01:39,800
data, especially if your service
is actually change system state.

37
00:01:39,850 --> 00:01:42,560
Modify core data. 
It's not just about spinning up 

38
00:01:42,570 --> 00:01:45,040
servers, it's the whole 
ecosystem you have to replicate.

39
00:01:45,110 --> 00:01:46,170
It's tricky. 
Right. 

40
00:01:46,180 --> 00:01:49,060
And here's where it gets, well, 
really interesting for today's 

41
00:01:49,070 --> 00:01:51,090
chat. 
The traditional load testing 

42
00:01:51,100 --> 00:01:54,260
model kind of falls apart when 
you bring in asynchronous parts.

43
00:01:54,330 --> 00:01:57,300
Those fire and forget things 
like sending an e-mail 

44
00:01:57,310 --> 00:02:00,600
notification maybe, or 
background processing. 

45
00:02:00,670 --> 00:02:04,820
The bit the user sees directly 
might look totally fine, instant

46
00:02:04,830 --> 00:02:08,759
success message, but what could 
be going wrong sort of silently 

47
00:02:08,770 --> 00:02:09,919
downstream? 
Exactly. 

48
00:02:09,930 --> 00:02:12,130
That's the trap the article 
warns about. 

49
00:02:12,210 --> 00:02:14,520
We might look at the initial 
response and think great 

50
00:02:14,570 --> 00:02:17,760
applications performing well, 
but we might be completely 

51
00:02:17,770 --> 00:02:20,040
missing struggles happening 
further down the line. 

52
00:02:20,130 --> 00:02:22,780
The key thing, the shift is in 
the metric. 

53
00:02:22,850 --> 00:02:26,040
For the synchronous part, yeah, 
requests per second latency, 

54
00:02:26,050 --> 00:02:28,560
that still matters. 
But for the asynchronous stuff, 

55
00:02:28,630 --> 00:02:29,990
we need to measure something 
different. 

56
00:02:30,030 --> 00:02:33,770
It's the execution time from the
moment that event or command 

57
00:02:33,780 --> 00:02:36,050
hits the message queue. 
You know, the place where tasks 

58
00:02:36,060 --> 00:02:38,750
wait right up until it actually 
finishes being processed. 

59
00:02:38,880 --> 00:02:41,990
Ah, OK. 
So it's not about how fast we 

60
00:02:42,000 --> 00:02:45,350
toss the message into the queue.
It's all about how quickly it 

61
00:02:45,360 --> 00:02:48,400
gets picked up and fully handled
after it's been queued. 

62
00:02:48,410 --> 00:02:51,150
That lets you actually see the 
impact of those downstream 

63
00:02:51,160 --> 00:02:52,530
dependencies. 
Make sure you're not just 

64
00:02:52,540 --> 00:02:55,750
creating this huge backlog that 
eventually breaks things for the

65
00:02:55,760 --> 00:02:58,150
customer. 
That feels like a big mindset 

66
00:02:58,160 --> 00:02:58,970
shift. 
It really. 

67
00:02:58,980 --> 00:03:00,350
Is. 
And then there's that other big 

68
00:03:00,360 --> 00:03:04,140
one, the sort of common myth. 
Serverless means infinite scale,

69
00:03:04,150 --> 00:03:06,660
No worries. 
But the article basically says 

70
00:03:06,670 --> 00:03:10,200
hold on, not so fast. 
Yeah, this catches people out. 

71
00:03:10,210 --> 00:03:13,180
Serverless platforms, Yeah, 
incredibly elastic, no doubt, 

72
00:03:13,510 --> 00:03:17,990
but our own application 
architecture and even the cloud 

73
00:03:18,000 --> 00:03:21,220
provider quotas themselves, the 
built-in limits on your account,

74
00:03:21,230 --> 00:03:23,560
they can create real 
bottlenecks, unexpected ones. 

75
00:03:23,570 --> 00:03:26,750
So it's not just if serverless 
can scales, can scale fast 

76
00:03:26,760 --> 00:03:29,730
enough for your specific needs 
and without causing other 

77
00:03:29,740 --> 00:03:31,670
problems. 
Load testing for server has 

78
00:03:31,680 --> 00:03:34,450
suddenly becomes about finding 
and really pushing those cloud 

79
00:03:34,460 --> 00:03:37,390
limits, identifying throttling 
where the provider slows you 

80
00:03:37,400 --> 00:03:39,680
down and understanding what that
actually does to your 

81
00:03:39,690 --> 00:03:41,290
performance. 
You definitely don't want your 

82
00:03:41,300 --> 00:03:43,530
real users discovering those 
limits for you. 

83
00:03:43,720 --> 00:03:45,490
Finding them the hard way. 
Exactly. 

84
00:03:45,540 --> 00:03:48,970
So connecting it all back, the 
article really gives us 2 

85
00:03:49,040 --> 00:03:52,540
crucial differentiators for load
testing these modern systems. 

86
00:03:52,640 --> 00:03:55,950
One, don't just measure the 
immediate synchronous response 

87
00:03:55,960 --> 00:03:59,190
times, you absolutely have to 
track that asynchronous 

88
00:03:59,200 --> 00:04:03,130
execution time too, from queue 
to completion that finds a 

89
00:04:03,140 --> 00:04:07,250
hidden stuff. 
And two, always, always test 

90
00:04:07,260 --> 00:04:09,610
against your cloud provider 
quotas and your own 

91
00:04:09,620 --> 00:04:12,910
architectural limits. 
Even with serverless confirm, 

92
00:04:12,920 --> 00:04:15,440
they can actually scale up 
quickly and effectively when 

93
00:04:15,450 --> 00:04:18,089
demand hits. 
So wrapping this up, what does 

94
00:04:18,100 --> 00:04:21,670
this mean for you, the listener?
Well, the main take away seems 

95
00:04:21,680 --> 00:04:24,010
clear. 
Doing these kinds of specialized

96
00:04:24,020 --> 00:04:26,490
load tests regularly means 
you're finding and fixing 

97
00:04:26,500 --> 00:04:28,550
problems before they hit your 
users. 

98
00:04:28,720 --> 00:04:31,470
It's about making sure your 
systems are genuinely resilient,

99
00:04:31,520 --> 00:04:34,010
ready for the unexpected. 
It's really about building 

100
00:04:34,020 --> 00:04:36,100
confidence. 
For more detailed information 

101
00:04:36,110 --> 00:04:38,410
and links to resources we 
touched on today, please do 

102
00:04:38,420 --> 00:04:40,070
check out the description for 
this discussion. 

103
00:04:40,140 --> 00:04:41,950
And hey, don't forget to 
subscribe. 

104
00:04:41,960 --> 00:04:44,690
It's free to the Architecture 
Corner newsletter over at 

105
00:04:44,700 --> 00:04:46,770
Architecture Corner 
substack.com. 

106
00:04:46,820 --> 00:04:48,930
It's the best way to stay 
informed on all things 

107
00:04:48,940 --> 00:04:49,510
architecture.