One thing that Joot found helpful was that for each event in EventBridge, the easiest way to keep things simple was to create handlers. Those handlers (shown below) are very simple lambdas. They are responsible for listening for an event, handling the event itself, and then performing whatever calls to other lambda functions that they may have in a microservice.

Not only do serverless services handle scaling for you automatically, the way services such as AWS Lambda are architected make it less likely to suffer from noisy neighbor issues that are prevalent on traditional server based applications.

When you build a traditional server-based application that then gets hosted on virtual machines (or container clusters that are hosted on virtual machines) each server will be processing multiple threads simultaneously on the same CPU and memory. For example, in an API backend, if multiple client requests are made to the backend, those requests will initiate invocations of application code in separate threads within the OS. If one of those threads happens to be non-optimal, it would consume more CPU resources for example or use more memory. With less resources available to process these less efficient requests, that means less simultaneous threads can be processed on the same infrastructure, and the larger the cluster will need to be to handle that request.

If the code is inefficient enough, it can escalate the issue resulting in the existing clusters of virtual machines being overwhelmed with traffic and the application as a whole not being able to spin-up enough additional capacity in time to prevent the cascading effect of everything just falling over.

This means that right up front, teams need to invest at least some effort in proving the performance of the application which can be difficult to do when your primary focus is building features, and requires time and resources to load test your app.

Let's move this to a serverless world where that same slightly inefficient code is executed in AWS Lambda instead. There are tests that have been done that show that the “noisy neighbor” effect between multiple Lambda functions is small-to-insignificant. Lambda functions are so well isolated, that an inefficient piece of code doesn’t create a cascading effect that brings down an entire cluster. At worst, you see latencies for requests go up. And the moment you realize this is happening you can refactor your service.

With Serverless, you can get the feature out first, then optimize later with the confidence that it will scale.