Microservices architecture for eCommerce with examples

by Ned Hallett
As Digital Marketing Manager and JAM’s primary pair of lungs, I provide the JAM-y take on the ever-evolving worlds of DevOps, SaaS, MACH - and acronyms yet to be coined.
Published on March 2023

Unless you’ve been living under a rock (or perhaps a monolith of some kind) you’ll have heard about the match made in heaven that is eCommerce and microservices. 

Scaleable, modular and fault-resistant, microservice-based architectures align with eCommerce brands’ key objectives. So, we thought we’d delve into the architecture, provide some handy examples, and talk about why this is a marriage made to last. First things first.

What are microservices? 

Microservices are a style of program architecture in which the application is composed of many small (some might even say micro), modular, discrete services.

Unlike monolithic applications, microservice architecture elements can be changed up and swapped out without disrupting the overall application. 

You can think of a monolithic application as a mighty (but samey) oak tree. On the other hand, a dynamic microservices garden can have new flowerbeds put in without unearthing the garden shed.

Now, let’s have a look at how they work.

 A modern, headless microservices architecture for eCommerce (example 1)

The above does a pretty good job of showcasing the relative benefits of a microservice-based architecture for eCommerce. 

But to understand what’s going on, we need to run through each element.

The knuckle-dragging monolith (left)

The site one undifferentiated version of the site served to all users who land on it.

Front end the code that takes the CMS content and shows it to the user.

Traditional CMS your standard WordPress et al. 

Admin UI the level at which the user edits and creates content. 

eCommerce services your order management system (OMS), product information system (PMS) and other familiar eCommerce mainstays all horribly and irrevocably blended together like fruit in a Nutribullet.

The dynamic, vivacious microservices (right)

The site and the app? And the IoT?? to understand this we have to go down the architecture. As we can see, each point of presentation has its own front-end element, this is made possible by the commerce API’s communication with the headless CMS, enabling a CaaS approach to your eCommerce content.

Multiple front ends, the commerce API and the headless CMS – in a headless CMS, content is decoupled from the front end. Instead, an API acts as an intermediary, allowing a single version of the content to be modified and adapted to different front ends, from websites and apps to point of sale of devices and more. 

Admin UI – here the admin works with the commerce API both to send headless content to multiple touch points and to communicate with the eCommerce services, see below.

Multiple eCommerce microservices – here the various eCommerce elements (PIM, OMS, etc.) are paired like fruits in a delicious fruit salad, which the host might completely rearrange, as is their right.

The above is a pretty good overview of a modern eCommerce app using microservices in conjunction with a headless CMS for nice, quick and clean architecture. But for our next example, we’re going to be tightening the microscope even further, and taking a look at the anatomy of a microservice itself.

The anatomy of an eCommerce microservice (example 2)

In an eCommerce architecture (other contexts are available) the elements of a microservice are as follows:

1. The container 

As we’ve explained elsewhere (comprehensively and in limpid prose) containers are essentially smaller, lighter versions of VMs. The lack of a host OS makes them lightweight and robust, and typically, a single container will host a single microservice as well as its dependencies.

There are many container and container orchestration technologies on the market, including Kubernetes and EKS, many of which will be integrable with your trusty service mesh. See below.

2. The service mesh 

The service mesh is a dedicated infrastructure layer that primarily handles communication between each microservice. 

So, when the shopping cart needs to tell the payment portal to open up, the service mesh is on the job. Service meshes will also handle load balancing, service discovery and health checking.

There are many solutions on offer from AWS App Mesh to open-source options like Istio and Linkerd.

3. The API gateway 

As we saw in the previous example, the API gateway handles communication externally. In a headless CMS, it will communicate with the front-end elements, as well as authenticating, rate limiting and request routing.

Amazon API Gateway is a good option for AWS users, while open-source alternatives include Kong and Tyk.

Advantages of microservices for eCommerce

Now that we’ve delved into the grisly innards of eCommerce architecture, it’s time to mix another metaphor and ask why these particular innards are the dog’s breakfast. Here are 7 very good reasons.

1. Decoupled front end and back end for scaling 

Because the front end is decoupled from the back-end services, mass traffic to your digital storefront won’t put an extra load on the microservices delivering in the background.

2. Independent service scaling 

Because each service is separated and containerised, you can scale one without scaling another. 

This means your shopping cart can scale up and down while your payment portal remains zen-like and unchanged. This keeps your eCommerce store running smoothly (and cheaply) in heavy traffic conditions.

3. Technology and skill set diversity 

To a degree, each microservices can be approached by a different development framework, coded in a different language and so on. This can be a great way to try something new or experiment with new talent. 

However, this can get out of hand. And a lot of the management in microservices can end up being about keeping people on the same page.

4. Best-of-breed selection 

Of course, there’s no need to design the services yourself. Going with a more composable commerce-type approach means you can choose the services that fit your application best and not be tied to a specific vendor.

5. Fault tolerance 

The advantage here is twofold. Firstly, because microservices are small and discrete, it’s easier to pinpoint the troublemaker when something’s not going as it should. 

Secondly, a well-architected microservices application will be designed to avoid a ‘cascade effect.’

So when one service goes down, the rest will stay stalwart.

6. Rapid implementation

Again, due to the granularity and modularity of microservices, teams will be able to release new features, update software and add entirely new services much more speedily. 

This is a special boon to eCommerce brands, who no longer need to spend months prepping to add a new feature to the shopping cart or revamp the site for a season sale.

7. Avoids feature lock-in

One of the main problems with all-in-one eCommerce platforms is that you end up paying (and sometimes through the proverbial nose) for features you may never use. The costs of AI-enabled customer recommendations and other surplus bells and whistles are often baked into the licence.

But with microservices – or a similarly composable approach – you quite literally get what you pay for. 

How we can help 

As a cloud-native MSP providing 1) eCommerce managed services and 2) 3-tiered mixed metaphors, it’s safe to say this dog’s breakfast is our bread and butter.

We’ve delivered next-gen architectures and trailblazing full-stack support to leading eCommerce brands.

So to talk to us about your eCommerce brand, just get in touch. Or read more about our approach to eCommerce here.



With partners across the USA, Europe and APAC, we provide a truly global service. So wherever you or your clients are based, contact us today to find out what we can do.