AWS Feed
Architecting a Highly Available Serverless, Microservices-Based Ecommerce Site
The number of ecommerce vendors is growing globally—they often handle large traffic at different times of the day and different days of the year. This, in addition to building, managing, and maintaining IT infrastructure on-premises data centers can present challenges to ecommerce businesses’ scalability and growth.
This blog provides you a Serverless on AWS solution that offloads the undifferentiated heavy lifting of managing resources and ensures your businesses’ architecture can handle peak traffic.
Common architecture set up versus serverless solution
The following sections describe a common monolithic architecture and our suggested alternative approach: setting up microservices-based order submission and product search modules. These modules are independently deployable and scalable.
Typical monolithic architecture
Figure 1 shows how a typical on-premises ecommerce infrastructure with different tiers is set up:
- Web servers serve static assets and proxy requests to application servers
- Application servers process ecommerce business logic and authentication logic
- Databases store user and other dynamic data
- Firewall and load balancers provide network components for load balancing and network security
Monolithic architecture tightly couples different layers of the application. This prevents them from being independently deployed and scaled.
Microservices-based modules
Order submission workflow module
This three-layer architecture can be set up in the AWS Cloud using serverless components:
- Static content layer (Amazon CloudFront and Amazon Simple Storage Service (Amazon S3)). This layer stores static assets on Amazon S3. By using CloudFront in front of the S3 storage cache, you can deliver assets to customers globally with low latency and high transfer speeds.
- Authentication layer (Amazon Cognito or customer proprietary layer). Ecommerce sites deliver authenticated and unauthenticated content to the user. With Amazon Cognito, you can manage users’ sign-up, sign-in, and access controls, so this authentication layer ensures that only authenticated users have access to secure data.
- Dynamic content layer (AWS Lambda and Amazon DynamoDB). All business logic required for the ecommerce site is handled by the dynamic content layer. Using Lambda and DynamoDB ensures that these components are scalable and can handle peak traffic.
As shown in Figure 2, the order submission workflow is split into two sections: synchronous and asynchronous.
By splitting the order submission workflow, you allow users to submit their order details and get an orderId. This makes sure that they don’t have to wait for backend processing to complete. This helps unburden your architecture during peak shopping periods when the backend process can get busy.
The details of the order, such as credit card information in encrypted form, shipping information, etc., are stored in DynamoDB. This action invokes an asynchronous workflow managed by AWS Step Functions.
Figure 3 shows sample step functions from the asynchronous process. In this scenario, you are using external payment processing and shipping systems. When both systems get busy, step functions can manage long-running transactions and also the required retry logic. It uses a decision-based business workflow, so if a payment transaction fails, the order can be canceled. Or, once payment is successful, the order can proceed.
Amazon Simple Notification Service (Amazon SNS) notifies users whenever their order status changes. You can even extend Step Functions to have it react based on status of shipping.
![Sample AWS Step Functions asynchronous workflow that uses external payment processing service and shipping system](https://d2908q01vomqb2.cloudfront.net/fc074d501302eb2b93e2554793fcaf50b3bf7291/2021/07/14/Figure-3.-Sample-AWS-Step-Functions-asynchronous-workflow.jpg)
Figure 3. Sample AWS Step Functions asynchronous workflow that uses external payment processing service and shipping system
Product search module
Our product search module is set up using the following serverless components:
- Amazon Elasticsearch Service (Amazon ES) stores product data, which is updated whenever product-related data changes.
- Lambda formats the data.
- Amazon API Gateway allows users to search without authentication. As shown in Figure 4, searching for products on the ecommerce portal does not require users to log in. All traffic via API Gateway is unauthenticated.
![Microservices-based product search workflow module with dynamic traffic through API Gateway](https://d2908q01vomqb2.cloudfront.net/fc074d501302eb2b93e2554793fcaf50b3bf7291/2021/07/14/Figure-4.-Microservices-based-product-search-workflow-module-with-dynamic-traffic-through-API-Gateway.jpg)
Figure 4. Microservices-based product search workflow module with dynamic traffic through API Gateway
Replicating data across Regions
If your ecommerce application runs on multiple Regions, it may require the content and data to be replicated. This allows the application to handle local traffic from that Region and also act as a failover option if the application fails in another Region. The content and data are replicated using the multi-Region replication features of Amazon S3 and DynamoDB global tables.
Figure 5 shows a multi-Region ecommerce site built on AWS with serverless services. It uses the following features to make sure that data between all Regions are in sync for data/assets that do not need data residency compliance:
- Amazon S3 multi-Region replication keeps static assets in sync for assets.
- DynamoDB global tables keeps dynamic data in sync across Regions.
Assets that are specific to their Region are stored in Regional specific buckets.
Amazon Route 53 DNS web service manages traffic failover from one Region to another. Route 53 provides different routing policies, and depending on your business requirement, you can choose the failover routing policy.
Best practices
Now that we’ve shown you how to build these applications, make sure you follow these best practices to effectively build, deploy, and monitor the solution stack:
- Infrastructure as Code (IaC). A well-defined, repeatable infrastructure is important for managing any solution stack. AWS CloudFormation allows you to treat your infrastructure as code and provides a relatively easy way to model a collection of related AWS and third-party resources.
- AWS Serverless Application Model (AWS SAM). An open-source framework. Use it to build serverless applications on AWS.
- Deployment automation. AWS CodePipeline is a fully managed continuous delivery service that automates your release pipelines for fast and reliable application and infrastructure updates.
- AWS CodeStar. Allows you to quickly develop, build, and deploy applications on AWS. It provides a unified user interface, enabling you to manage all of your software development activities in one place.
- AWS Well-Architected Framework. Provides a mechanism for regularly evaluating your workloads, identifying high risk issues, and recording your improvements.
- Serverless Applications Lens. Documents how to design, deploy, and architect serverless application workloads.
- Monitoring. AWS provides many services that help you monitor and understand your applications, including Amazon CloudWatch, AWS CloudTrail, and AWS X-Ray.
Conclusion
In this blog post, we showed you how to architect a highly available, serverless, and microservices-based ecommerce website that operates in multiple Regions.
We also showed you how to replicate data between different Regions for scaling and if your workload fails. These serverless services reduce the burden of building and managing physical IT infrastructure to help you focus more on building solutions.