Building a Serverless Event-Driven Retail Order Management System

The ecommerce market has seen significant year-over-year growth in the past few years. Customer buying behavior has shifted online, even as new trends like buy-online-pickup-in-store are becoming prevalent. According to the US Census Bureau, US retail ecommerce sales in 2022 were estimated at over a trillion dollars, and grew 7.7% from 2021.

Retailers have made significant investments in digital commerce, but still struggle to stay on top of ecommerce traffic, especially during peak sales events like Black Friday. To stay abreast with changing consumer behavior, retailers must not only migrate their monolithic applications to the cloud, but take full advantage of cloud native technologies.

This blog talks about how refactoring or rebuilding a retail order management system, using an asynchronous event-driven approach with serverless services can help retailers improve resiliency, scalability and help them focus more on innovation.

After experiencing a severe outage during a Black Friday sales event, LEGO refactored their monolithic ecommerce platform. During a typical sales event, LEGO could see online transaction spikes of up to 200 times and user traffic of up to 9.5 times. Refactoring their platform using a serverless event-driven approach allowed them to handle peaks in traffic without glitches.

Neiman Marcus, a luxury retailer based in the US, achieved 50% faster application launch times, while increasing developer agility and reducing costs, by using a strangler fig migration pattern to serverless.

Why choose a serverless event-driven architecture

Dr. Werner Vogels in his re:Invent 2022 keynote pointed out that the world is event-driven and inherently asynchronous. Consider a retail order management system: When a customer places an order on an ecommerce website, that is an event. The customer can almost immediately be notified that their order was received. Meanwhile the rest of the order processing can be handled asynchronously through decoupled services.

For example, the payment service can independently process payments and return the status. The inventory service can check if the product is in stock and notify the system. These various services would communicate with each other through a central hub called the Event Broker, which receives and passes events.

Now that we have talked about why event-driven architectures make sense, let’s consider serverless. Serverless and event-driven architectures go hand-in-hand because serverless services, like AWS Lambda, are built to trigger on events. You only pay when an event is being processed.

To summarize the benefits of a serverless event-driven architecture:

1. Resiliency – The benefit of a loosely-coupled system is that when one component in a loosely coupled system fails, the failure is isolated to that component but the rest of the system remains unaffected. For example, when the shipment service goes down, it doesn’t affect the checkout service. Hence customers can continue to place orders online while developers work on fixing the shipment service. LEGO’s decision to build on AWS using serverless was prompted by an outage of almost 2 hours during a highly anticipated sales event.
2. Scalability – Serverless services automatically scale upon request without any need for provisioning. Being serverless allows the system to automatically scale up during peak demand and scale back down during quiet times, thereby saving cost. In addition, loosely-coupled services can scale independently of each other. Taco Bell added 4 delivery partners in 6 months to their online delivery system by building a serverless event-driven middleware solution.
3. Speed and Agility – Serverless applications are straightforward to build, and experiment with. Because of the loosely coupled nature of event-driven architecture, it is quick to evolve the architecture or add new features to existing applications. MatHem.se, Sweden’s largest online-only grocery retailer, adopted a serverless and decoupled architecture to build their ecommerce site on AWS, allowing them to innovate up to 10 times faster.

Retail order management flow

The following diagram shows a conceptual view of how events flow in a sample retail order management system and how they can be used to build a loosely-coupled ecommerce system.

Event flow in a sample retail order management system

This example shows the following services: CheckOut Service, Order Service, Fulfillment Service, Warehouse Service and Notification Service. These services are built as independent microservices, which allows them to scale independently and fail independently without affecting the other components. The different services do not communicate directly with each other, but go through an Event Broker. A service would publish an event to the Event Broker upon completion of a task, and other services (who are interested in that particular event) would subscribe to it. Let’s take a look at the flow of events, from when the customer orders an item, to when it is shipped:

1. When the customer orders an item, the Checkout Service publishes an OrderCreated event.
2. The Order Service subscribes to the OrderCreated event.
3. The Order Service processes the payment and creates an OrderProcessed event.
4. The Fulfillment Service subscribes to the OrderProcessed event.
5. Upon getting the event it starts the fulfillment process and, when completed without errors, it publishes the ShipmentPrepared event.
6. The Warehouse Service subscribes to the ShipmentPrepared event.
7. This notifies the warehouse personnel to pack the items. When completed, the Warehouse Service publishes the ShipmentProcessed event.
8. The Fulfillment Service subscribes to the ShipmentProcessed event.
9. Upon getting the ShipmentProcessed event, it finalizes the fulfillment and publishes the OrderFulfilled event.
10. The Notification Service subscribes to all the relevant events to keep the customer notified of the progress of their order—from order placement to shipment.

The concept of an event-driven architecture to build loosely-coupled systems can be applied to use cases across many industries. Some other examples are banking and insurance (example, loan processing and insurance processing), customer service, and manufacturing.

Composable Commerce and MACH

Retailers using a Composable Commerce approach (using the prescriptive guidance of the MACH Alliance, an organization in which AWS participates as a technology enabler) can still adopt this serverless event-driven pattern to build the order management piece of their ecommerce system. MACH (which stands for Microservices-based, API-first, Cloud-native SaaS and Headless) allows retailers to choose best-of-breed solutions and put together (or self-build) pieces of their platform to build a future-proof pluggable solution.

Conclusion

This blog described a serverless event-driven architecture for retail order processing. Ecommerce systems built using microservices and cloud native technologies like serverless help retailers stay ahead of their competition by increasing time to market, resiliency and scalability, and reducing cost.

Resources to learn more:

• Event-driven Architectures on Serverless Land
• A Perfect Marriage: Ecommerce on AWS
• Capturing the Power of Digital Commerce