Welcome to the Architecture Corner.
Today we're diving into the fascinating world of load
testing, but with a really crucial twist.
We're looking at the unique challenges, often kind of
overlooked, that pop up with serverless and asynchronous
applications. This whole discussion is sparked
by a really insightful article, Load Testing Serverless
Asynchronous Applications Practical Considerations by
Mario Bittencourt. He really unpacks why our usual
ways of checking if a system is ready might well give us a
dangerously incomplete picture when things were distributed and
working asynchronously. Yeah, it's interesting how the
article just immediately grounds us in today's reality
applications. Now they're rarely just one big
thing, right? That these complex mixes,
tapestries of connected services.
And our goal always is to figure out if our system can actually
handle those demand spikes, you know, whether they're planned or
just come out of the blue. Load testing, like the article
says, it pushes us past just modeling things theoretically.
It forces that real world validation.
That's where you find the hidden problems.
OK, so let's unpack that. The basic idea of load testing
sounds simple enough. You send traffic, you measure
how it behaves against your Slas, your service level
agreements, those promises we make.
But the article points out some pretty big hurdles even before
we get to the sync or serverless stuff, right?
Oh, absolutely. Yeah.
A huge question right off the bat is how do you even simulate
production accurately? You need a whole separate setup
that's identical. That's a massive job, even using
infrastructure as code to automate things.
And then there's the data dependency problem.
Simulating real traffic often means you need real existing
data, especially if your service is actually change system state.
Modify core data. It's not just about spinning up
servers, it's the whole ecosystem you have to replicate.
It's tricky. Right.
And here's where it gets, well, really interesting for today's
chat. The traditional load testing
model kind of falls apart when you bring in asynchronous parts.
Those fire and forget things like sending an e-mail
notification maybe, or background processing.
The bit the user sees directly might look totally fine, instant
success message, but what could be going wrong sort of silently
downstream? Exactly.
That's the trap the article warns about.
We might look at the initial response and think great
applications performing well, but we might be completely
missing struggles happening further down the line.
The key thing, the shift is in the metric.
For the synchronous part, yeah, requests per second latency,
that still matters. But for the asynchronous stuff,
we need to measure something different.
It's the execution time from the moment that event or command
hits the message queue. You know, the place where tasks
wait right up until it actually finishes being processed.
Ah, OK. So it's not about how fast we
toss the message into the queue. It's all about how quickly it
gets picked up and fully handled after it's been queued.
That lets you actually see the impact of those downstream
dependencies. Make sure you're not just
creating this huge backlog that eventually breaks things for the
customer. That feels like a big mindset
shift. It really.
Is. And then there's that other big
one, the sort of common myth. Serverless means infinite scale,
No worries. But the article basically says
hold on, not so fast. Yeah, this catches people out.
Serverless platforms, Yeah, incredibly elastic, no doubt,
but our own application architecture and even the cloud
provider quotas themselves, the built-in limits on your account,
they can create real bottlenecks, unexpected ones.
So it's not just if serverless can scales, can scale fast
enough for your specific needs and without causing other
problems. Load testing for server has
suddenly becomes about finding and really pushing those cloud
limits, identifying throttling where the provider slows you
down and understanding what that actually does to your
performance. You definitely don't want your
real users discovering those limits for you.
Finding them the hard way. Exactly.
So connecting it all back, the article really gives us 2
crucial differentiators for load testing these modern systems.
One, don't just measure the immediate synchronous response
times, you absolutely have to track that asynchronous
execution time too, from queue to completion that finds a
hidden stuff. And two, always, always test
against your cloud provider quotas and your own
architectural limits. Even with serverless confirm,
they can actually scale up quickly and effectively when
demand hits. So wrapping this up, what does
this mean for you, the listener? Well, the main take away seems
clear. Doing these kinds of specialized
load tests regularly means you're finding and fixing
problems before they hit your users.
It's about making sure your systems are genuinely resilient,
ready for the unexpected. It's really about building
confidence. For more detailed information
and links to resources we touched on today, please do
check out the description for this discussion.
And hey, don't forget to subscribe.
It's free to the Architecture Corner newsletter over at
Architecture Corner substack.com.
It's the best way to stay informed on all things
architecture.