Highly scalable and performant e-commerce using Jamstack
It can be really hard to get cost-effective scalability from Digital eXperience Platform (DXP) based e-commerce sites. Applying multiple layers of caching might even lead to a situation in which we have to give up on functionality offered by the platform. For these kind of e-commerce sites performance cannot longer be an afterthought, we need an architecture build for this. Hello Jamstack!
Challenges with Digital eXperience Platforms
Content Management, Analytics, Marketing Automation, Machine Learning. These are some of the features offered by Digital eXperience Platforms and the actual list tends to be a lot longer. All these features require CPU and Memory to execute, even the ones that you might not even use. Consider the following typical DXP architecture:
From left to right we see a load balancer that spreads out the load over the three content delivery servers. The content delivery servers are dedicated roles of the DXP for serving the content. There is a separate content management server that is used by the content-editor and marketeers and a separate application server for background processing. When the visitor requests a page, the request-response cycle looks like this:
- The customer requests a page from the website
- The load balancer picks a content delivery server
- The content delivery server requests the necessary data from the database
- The content delivery server renders the page and serves the response to the customer
Say there is a project with this architecture and the team is finished building the launching features, they are ready for GO-live! As they are professionals, a load-test is performed first. The results come in and they don't look good. The product owner demands that the performance is improved!
The team downloads a copy of the DXPs performance guide. First, tuning on the DB is done and table indexes are added. Next, the caches on the Content Delivery (CD) servers need to be configured. Performance is a lot better already, to improve it even further, images and other static resources are pushed to a Content Delivery Network. Performance is acceptable now and the site's GO-live is a success.
A week later the team celebrates the success and go out for a team dinner. In the middle of the main course phones start ringing: the site is down. They open theirs laptops and notice that the number of visitors is a lot higher than expected. Further analysis shows that the CPU of the content delivery servers is maxed out. The team applies "Infrastructure as code" and they are able to add two more CD's within the hour, which fixes the issue. The next morning at the office, they hear that marketing has send out a big newsletter that resulted in the spike of traffic.
Right away they notice that the number of visitors is a lot higher than expected and that the CPU of the content delivery servers is maxed out
Two months later it's Cyber Monday... Again the team sees a enormous spike in traffic and this time the problem is not that easily resolved. They end up disabling features of the DXP in order to get an acceptable performance.
When it comes to DXP based e-commerce sites with these visitor numbers, it can be really hard to scale the system. Especially with extreme peek moments. The costs and complexity of the infrastructure involved make it hard to get a return on investment on the DXP.
Performance should not longer be an after-thought. We need an e-commerce architecture optimized for scalability.
Reverse the flow
This term was used by Netlify CEO Matt Biilmann in his State of Jamstack keynote (October 2020) to explain Netlify's goal when they started out. In the example earlier, the customer requests a page and that page gets build on the fly. When the cache expires, it gets build again, even when the underlying data hasn't been changed. What if instead, we reverse the flow and pre-built the page and re-built it only when the underlying data changes? Going even further, we can even push this static page to a Content Delivery Network (CDN). This way the page always sits close to the visitors, resulting in optimal performance.
Companies like Netlify and Vercel have e-volved Content Delivery Networks to what they call Application Delivery Networks (ADN). Traditionally CDNs only serve static assets. Application Delivery Networks have additional features to build your application, hooks that can be used to re-build when data changes, more advanced cache invalidation, etc.
Instead of building everything on the fly, we can detect when anything changes and pre-built as much as possible in a build step and push it out to the edge layer
Matt Biilmann
Consider the example of the team's production issues. With this architecture, the pages are pre-built and served by the CDN. The CDN will handle all the scaling and the application will have no issues, even in the Cyber Monday scenario.
Jamstack
Jamstack stands for JavaScript, API's & Markup and is the result of the 'reverse the flow' idea. Static pages are pre-built and re-built when the data changes. The markup of these pages is pushed to a ADN and contains JavaScript to enhance them. This JavaScript invokes API's to provide additional functionality.
Next to the performance and scalability improvements of this approach, there is a big improvement when it comes to the developer experience. With DXP's the developers are limited by the technology used by the platform. By using a headless CMS instead, that only serves data instead of markup, the front-end is decoupled from the CMS. The developers are free in their choice of technology, allowing them to use the best tool for the job and to create amazing visual experiences.
By using headless services and having a decoupled front-end also means no more expensive platform upgrades. The only coupling is through the HTTP endpoint and most services guarantee backwards compatibility. New features that require breaking changes are usually added through a new API. Headless services are great to be consumed as Software as a Service, meaning less infrastructure to manage and better quality of service.
API Economy
These days, there is an API for everything. Before, if you wanted to send an SMS, it was really hard to do. Now, it's just one API call using a service called Twilio. This API economy makes it really easy to build Jamstack websites with amazing capabilities without the complexity normally involved. Also, with a DXP platform, developers and users have to deal with the complexity of the entire platform from the beginning. With the Jamstack approach, the solution can start out simple and services (and their added complexity) get added incrementally when they are needed.
Dealing with large catalogs
Jamstack sites are statically generated. Every time the content changes, the entire site will be re-generated to display the changed content. This works well with personal blogs or small sites, but what about an e-commerce site with 300.000 products and thousands of product updates every day? Generating a site with that many pages would be slow and it would take a long time for the updated product data to be visible on the site.
Incremental Static Regeneration
Fortunately, most static site generators offer some form of incremental builds. For example, Gatsby, a React based static site generator, has incremental builds that magically speed up builds by comparing changes and only rebuilding necessary pages. Next.js offers a different solution. Next.js is different from pure static site generators, because it is more of a hybrid. Besides Static Site Generation (SSG) it also supports Server Side Rendering (SSR) and Incremental Static Regeneration (ISR). Server Side Rendering is more like the traditional on-demand rendering and it is considered best practice to not use this. However, it's good to keep this option available, might it be needed in a later stage. With Increment Static Regeneration it's possible to serve a pre-build version of a page, while in the background a new version gets re-generated, that will be served to the next visitor. This is achived by using a CDN mechanism called Stale-while-revalidate. We think ISR is the perfect solution for large e-commerce sites, because it allows for fast builds, high performance and up-to-date data.
We think Incremental Static Regeneration (ISR) is the perfect solution for large e-commerce sites, because it allows for fast builds, high performance and up-to-date data.
What about personalization?
There are multiple personalization solutions that rely on client-side JavaScript like Optimizely or Google optimize. The downside of these solutions is the the amount of JavaScript needed can have a negative impact on the perceived performance and might present your users with a flash of changing content. An interesting alternative is doing personalization on the edge. More and more Content Delivery Networks (Cloudflare, Netlify) allow you to run code on their edge servers. Uniform and Outsmartly are new players in this field that use this to enable personalization using CDN edge servers. This allows for super fast personalization!
Even Especially for large scale e-commerce
The complex infrastructure, large number of features and legacy code of monolithic Digital Experience Platforms make it hard to efficiently scale e-commerce solutions. Not all hope is lost, reverse the flow and incrementally regenerate the static pages! Serve them from a CDN and scalability issues are a thing of the past. Adding innovative services has never been easier by the way the Jamstack enables you to get the most from the API economy.
Want to know more?
Do you have a question, would you like to know more or would you like to see our exciting Jamstack storefront demo? Use our contact form or drop us a mail: info@unplatform.io.
