Mar 12
AWS Lambda Best Practices and Event-driven Architecture
In this article, we are going to learn about AWS Lambda Best Practices and Event-driven Architecture when developing Serverless E-Commerce application.
At the end of the article we will be following the Reference Architecture above which is a Real-world Serverless Event-driven E-commerce application.
Step by Step Design AWS Architectures w/ Course
I have just published a new course — AWS Serverless Microservices with Patterns & Best Practices.
In this course, we’re going to learn how to Design and Develop AWS Serverless Event-driven Microservices with using AWS Lambda, AWS DynamoDB, AWS API Gateway, AWS EventBridge, AWS SQS, AWS CDK for IaC — Infrastructure as Code tool and AWS CloudWatch for monitoring.
Source Code
Get the Source Code from Serverless Microservices GitHub — Clone or fork this repository, if you like don’t forget the star. If you find or ask anything you can directly open issue on repository.
AWS Lambda Best Practices and Event-driven Architecture
We will follow lambda design principles and the best practices when developing our Lambda-based Event-driven Serverless e-commerce applications.
Lambda is very good fit with event-driven architectures, because the nature of lambda executions trigger from events. Events can come lots of resources and able to trigger lambda functions.
Lambda is a compute service that runs custom function code and return response to events. Most AWS services generate events for communicating each other, and most of AWS Services are event sources for Lambda.
Lambda always handle all interactions with the Lambda API and there is no direct invocation of functions from outside the service. You can see the image below, lambda handle event with the Lambda API. The main purpose of lambda functions is to handle events.
When a function is triggered by an event, this is called an invocation.
Lambda functions are limited to 15 minutes in duration, but on average, most calls take less than a second across all AWS customers. In some compute intensive operations, it may take several minutes to process a single event, but in most cases the time is short.
An event triggering a Lambda function could be almost anything, you can see in the image, from REST API HTTP request with Amazon API Gateway, a schedule task managed by an Amazon EventBridge rule, or an Amazon S3 notification like object uploaded into bucket.
Even the simplest Lambda-based application uses at least one event. So that's why we said, AWS Lambda is very good fit for the Event-Driven Architectures. Because the fuel of AWS Lambda is events.
AWS Lambda Events
The event is a JSON object that contains all information about what happened. Events are represents a change in the system state, they are immutable. You can see example event json to trigger AWS Lambda function in the image.
The first parameter of every Lambda handler function contains the event json object. So, Here you can find example event json object that trigger to lambda function. You can see the function image that take event parameter into lambda handler method.
So at that stage, the event parameter is very important when developing your Lambda function. If you look at the Lambda handler method, you will see that the first parameter is event into Lambda Handler method.
So with using this event json object, we can access the event parameters into lambda function. For example lets look at the above event json object image;
We have new Order event triggers to lambda function so if I would like to order.detail attribute value into lambda function basically I can take information with event.source or event.detail into my lambda handler function, because lambda triggered with this event json object with passing parameter into handler method.
An event could be custom-generated from another microservice, such as new order generated in an ecommerce application. We will have exactly same use cases into our serverless e-commerce application.
The event also can be generated from existing AWS service, like Amazon SQS when a new queue message is available in a queue, it can trigger to lambda with polling queue records from AWS SQS.
Event-driven architectures rely on creating events into all application state changes that are observable by other services, but the event publisher system is unaware of which consumers are subscribing that event. We call that, these are loosely coupled services.
Most Lambda-based applications use a combination of AWS services, for different requirements about Storage, API Management and integrating with other system and services.
In these applications, Lambda is connecting between services, providing business logic to transform data that moves between services.
AWS Lambda Design Principles and Best Practices with Event-driven Architectures
Now we can talk about design principles and the best practices when developing Lambda-based event-driven applications.
So we said that Serverless applications mostly using with combination of several AWS services, that integrated with custom code run in Lambda functions.
You can find mostly integrated AWS Services which using Lambda functions. you can see in the image below, These services most commonly using in serverless applications with AWS Lambda functions.
We will also use these services into our serverless e-commerce application.
Also There are some design patterns in distributed architectures that we will follow when build and implement application using AWS services.
AWS Services has already implement some of distributed architectures design patterns that we can use easily without investing time to develop these patterns from scratch.
When your application needs one of these patterns, we can use the corresponding AWS service: you can see table in the below;
These services and patterns are designed to integrate with AWS Lambda functions and we can also use infrastructure as code (IaC) to create and destroy resources in the AWS Services.
We can use any of these services with using the AWS SDK without needing to install applications or configure servers. So these are the best practices when designing well-designed serverless applications that we will follow when developing our serverless e-commerce application.
As a summary, in serverless world, Lambda is core services for building any event-based architectures. That means we will also follow these lambda design principles and the best practices when developing our Lambda-based event-driven serverless e-commerce applications.
Basically we will group these events as bounded contexts in order to develop the boundaries of the microservices in our serverless e-commerce application. That means we will develop lambda functions as a microservices into our event-driven microservices architecture.
AWS Serverless Microservices with Event-Driven Lambda Invocations
So we will also follow these lambda design principles and the best practices when developing our Lambda-based event-driven serverless e-commerce applications.
We will map Event-driven Lambda Invocation Types, So AWS Lambda Invocation Types will be our Serverless Integrations when developing our Serverless e-commerce application.
If we map these Lambda Invocation Types with our microservices architecture when developing serverless e-commerce application, you can see the diagram below;
So AWS Lambda Invocation Types will be our Microservices Communications when developing our Serverless Event-driven E-commerce Microservices application.
So during the article, we will follow these Lambda Invocation types as a Microservices Communication types of our serverless e-commerce microservices project.
Lambda Invocation Types = Sync -> Async -> Event Mapping
Following Microservices Communication Types for Serverless
- Synchronous Communication
- Asynchronous Communication
- Event Source Mapping for Poling queue events
So how we can follow these invocation types into our application ?
Synchronous Communication for RESTful Microservices
Synchronous commands are request/response. In a synchronous model, the client makes a request and waits for a response. We will developed RESTful Microservices with API Gateway, Lambda Functions and DynamoDB.
We called this = RESTful Microservices
- REST API and CRUD endpoints (AWS Lambda, API Gateway)
- Data persistence (AWS DynamoDB)
AWS API Gateway -for- Restful API-Driven Development for performing CRUD operations amongst lambda and DynamoDB.
Asynchronous Communication
In an asynchronous design, the client sends a request and may get an acknowledgement that the event was received, but it doesn’t get a response that includes the results of the request.
We will use
- Amazon EventBridge -for- Event-Driven asynchronous communication between Microservices
We will develop Amazon EventBridge with Lambda Basket microservices which publish the event in asynchronous way and this will consume by Ordering queue.
Event Source Mapping for Polling Event Messages
In a polling event, consumers poll the producer for messages in batches and then process the batch before returning for a new batch of records.
We will use
- AWS SQS -for- Decouple Microservices and processing events asynchronously using queues
We will develop AWS SQS with Lambda Ordering microservices which consumes by polling the event from the Ordering queue.
As you can see that we follow Serverless Microservices with AWS Lambda Invocation Types; Following Microservices Communication Types for Serverless;
- Synchronous Communication
- Asynchronous Communication
- Event Source Mapping for Poling events
AWS Serverless Microservices for Ecommerce Application Architecture
This is the big picture of what we are going to develop together for AWS Serverless Event-driven E-commerce Microservices application that is Step by Step Implementation together.
We have followed the reference architecture above which is a real-world serverless e-commerce application and it includes;
- REST API and CRUD endpoints with using AWS Lambda, API Gateway
- Data persistence with using AWS DynamoDB
- Decouple microservices with events using AWS EventBridge
- Message Queues for cross-service communication using AWS SQS
- Cloud stack development with IaC using AWS CloudFormation CDK
Step by Step Design AWS Architectures w/ Course
I have just published a new course — AWS Serverless Microservices with Patterns & Best Practices.
In this course, we’re going to learn how to Design and Develop AWS Serverless Event-driven Microservices with using AWS Lambda, AWS DynamoDB, AWS API Gateway, AWS EventBridge, AWS SQS, AWS CDK for IaC — Infrastructure as Code tool and AWS CloudWatch for monitoring.
Source Code
Get the Source Code from Serverless Microservices GitHub — Clone or fork this repository, if you like don’t forget the star. If you find or ask anything you can directly open issue on repository.
