How Lambda fits into the event-driven paradigm - AWS Lambda

How Lambda fits into the event-driven paradigm

Lambda is an on-demand compute service that runs custom code in response to events. Most AWS services generate events, and many can act as an event source for Lambda. Within Lambda, your code is stored in a code deployment package. All interaction with the code occurs through the Lambda API and there is no direct invocation of functions from outside of the service. The main purpose of Lambda functions is to process events.

event driven architectures figure 1

Unlike traditional servers, Lambda functions do not run constantly. When a function is triggered by an event, this is called an invocation. Lambda functions are purposefully limited to 15 minutes in duration but on average, across all AWS customers, most invocations only last for less than a second. In some intensive compute operations, it may take several minutes to process a single event but in the majority of cases the duration is brief.

An event triggering a Lambda function could be almost anything, from an HTTP request through API Gateway, a schedule managed by an EventBridge rule, an IOT event, or an S3 event. Even the smallest Lambda-based application uses at least one event.

event driven architectures figure 2

The event itself is a JSON object that contains information about what happened. Events are facts about a change in the system state, they are immutable, and the time when they happen is significant. The first parameter of every Lambda handler contains the event. An event could be custom-generated from another microservice, such as new order generated in an ecommerce application:

event driven architectures figure 3

The event may also be generated by an AWS service, such as Amazon SQS when a new message is available in a queue:

event driven architectures figure 4

In either case, the event is passed to the Lambda function as the first parameter in the Lambda handler:

event driven architectures figure 5

  1. The code outside of the handler, also known as “INIT” code, is run before the handler. This is used for tasks like importing libraries or declaring and initializing global objects.

  2. The handler itself is a function that takes the event object. Regardless of runtime used in the Lambda function, the event is a JSON object.

For simpler applications, the difference between event-driven and request-driven applications may not be clear. As your applications develop more functionality and handle more traffic, this becomes more apparent. Request-driven applications typically use directed commands to coordinate downstream functions to complete an activity. Event-driven applications create events that are observable by other services and systems, but the event producer is unaware of which consumers, if any, are listening.

Most Lambda-based applications use a combination of AWS services for durably storing data and integrating with other systems and services. In these applications, Lambda acts as glue between the services, providing business logic to transform data as it moves between services.

event driven architectures figure 6

Building Lambda-based applications follows many of the best practices of building any event-based architecture. A number of development approaches have emerged to help developers create event-driven systems. Event storming, which is an interactive approach to domain-driven design (DDD), is one popular methodology. As you explore the events in your workload, you can group these as bounded contexts to develop the boundaries of the microservices in your application.

To learn more about event-driven architectures, read What is an Event-Driven Architecture? and What do you mean by Event-Driven?