Building a resilient eCommerce platform with a JAMStack and Cloud-Native approach

Care to share?

Losing orders during a sales peak is a merchant’s nightmare. However, it is tough to build a resilient eCommerce platform; it requires implementing 24/7 SLAs, processes, DevOps teams, and tons of redundant servers… At least, that’s how it looked like years ago. If you’re brave enough to put an end to your legacy tech stack, you can build an almost unstoppable, always-available eCommerce platform that requires virtually no maintenance or support. Here’s how.

JAMStack is for the frontend

Failures in the eCommerce industry often start with an unpredictable success that leads to scalability issues. They say you can never have too much of a good thing. However, if that good thing is traffic and your platform is not capable of dealing with it, then you’ve got big problems.

The application development paradigm has changed and we’re heading towards more application-oriented and service-oriented tech stacks. Lifestyle development is no longer a gadget, it’s a feature that leads to better, more predictable results.

We could elaborate on how to scale up the Magento, Java web apps, or any other on-prem platforms to handle the traffic. However, this post is all about hacking the problem. What if we don’t have to deal with the app scalability at all?

I wrote about JAMStack in a recent post. JAM stands for JavaScript, API, and Markup. It’s how you build the frontend. Usually, the frontend application itself, which is built with JS and is consuming the API, is super-scalable. They can be pre-rendered into static files (yes, HTML files + JS) and put on a CDN. There are plenty of solutions you can use for hosting such apps, like Vercel, Heroku, Netlify. Some of them have the CDN (Content Delivery Network) included, others can be accelerated using Cloudflare, Cloudfront, or even AKAMAI for app delivery. You don’t have to worry about scaling the frontend app when you have such apps, because they support auto-scalability straight out of the box. They provide users with <100ms response times thanks to distributed networks.

All these platforms are well integrated with Github, Gitlab, and all the modern CI-CDs. You probably won’t even need to have the DevOps inside your team because the one-time setup is a piece of cake. Everything is then automated.

Github private repo + Github Actions are perfect ways to deploy the JAMStack application to the delivery network.

There are plenty of frameworks and tools for building a JAMStack-based app, starting with the Vue Storefront Next, which is based on a more general-purpose framework: Nuxt.js. If you prefer React, you can take Gatsby or Next.js

SEO is not an issue. You can use services like prerender.io if you didn’t use any of the frameworks mentioned in the previous sentence to still have the Server Side Rendered in full HTML markup to be indexed by Google.

These frameworks I’m suggesting, however, can be used for partially-regenerating the site as it’s changed. If you want dynamic content in the Server Side rendered product or category pages, that’s not a problem.

Scalability issues come from dynamic content and on-demand computing. Avoid it at all cost, move the business logic to the client’s machines (client-side JavaScript)

Serverless is for the backend

If your eCommerce frontend has been successfully delivered, that’s just the beginning of the customer journey that should eventually end with the placement of an order. This is a crucial service that should be available 100% of the time. 

You can take a shortcut and just deploy commercetools, which provides you with a set of always-available APIs that can be successfully used as a backend for virtually any transactional platform.

However, there are a lot of different cases, including those in which you need to cover up some legacy OMS eCommerce systems with internet-scale ready services to work with the frontend. In that case, I’d suggest you consider the Serverless approach

There can be many different arguments for Serverless but, in the context of this blog post, I’ll just note three of them which are important to help build a resilient eCommerce platform. 

First, serverless deployments—using Amazon Lambda or Google Functions—are extremely easy. You don’t have to have DevOps skills; you can just write your function and deploy it. There is no infrastructure and you won’t run into scalability problems. You simply have a very straightforward CI that is integrated with your favorite code repository. 

Secondly, the functions can be deployed globally, using services like Lambda@Edge or Cloudflare Workers (more on this later). This means they’re unstoppable. Deployed simultaneously to different geo-locations, there’s no way it can go down in all locations at once. 

Thirdly, the pricing is flexible because you’re paying for the number of requests, or computing time, but not for the idle time! This means significant savings for the business.

Cloudflare Workers

When I found the Cloudflare Workers, I was shocked. Of course, they offer the famous CDN service, but they now also support dynamic applications. And they do it in almost the exact opposite way to other Super Cloud providers (Azure, GCP, AWS).

They offer an execution model based on V8 Isolates, not the classic container-based execution model. This means the response times are fundamentally lower—usually less than 50ms.

Cloudflare Workers response times are beating AWS results by up to 7 times. Source: https://blog.cloudflare.com/serverless-performance-comparison-workers-lambda/ 

The isolates work like you’ve got a one-time V8 process initialization cost (in the other providers, you pay this cost virtually every time the request is executed)

Cloudflare Workers architecture is quite unique. It ends up with much better response times.

Your code is automatically deployed around the world into all Cloudflare CDN locations. The service includes Key Value Storage and programmable Caching

These services might help you save all the orders users are placing; however, it doesn’t solve the problem with the transactions/stock management.

KV achieves this performance by being eventually-consistent. Changes may take up to 60 seconds to propagate. Workers KV isn’t ideal for situations where you need support for atomic operations or where values must be read and written in a single transaction.

In eCommerce, the most crucial part of the order process is stock management. If you’re using a cloud-native platform like commercetools, this isn’t a problem because the Worker can always fetch the stock within 50-100ms.

If you need to work around your legacy WMS, I suggest you check out Redis or CockroachDB as a backend for the inventory microservice.

Building a resilient eCommerce platform: The summary

High availability is now much easier to achieve using the available application delivery platforms and techniques. You don’t have to have heavy, ITIL or ISO processes for maintaining the SLAs. You can order a service for that. You don’t have to even maintain the infrastructure either. 

In fact, even when building the most resilient eCommerce platform, all you need to do is focus on the design and development of your application. And that’s a lot of fun!

Headless eCommerce - Download FREE Book

Published October 27, 2020