Embracing headless commerce lets merchants and engineers completely reimagine the way they delight online shoppers and differentiate their brand from the ground up. It’s not the next iteration of traditional eCommerce infrastructure or online stores, it’s a new and different way to build entirely.
This reimagination of eCommerce infrastructure goes beyond the simple definition of “headless commerce” as a separation of the frontend and backend, but embodies the ethos of headless completely. Meaning leveraging eCommerce microservices and decoupling throughout the entire tech stack, including best-of-breed and custom tools on the backend.
Best-of-breed refers to using different vendors to leverage the best offering in each application area, including services you choose to build in-house to differentiate your brand and bolster your IP. Microservice architecture arranges these independent applications to work together.
Microservice architecture and best-of-breed tools will be the most conducive to your headless commerce goals, and put you in a position to be responsive to the ever-evolving eCommerce landscape. Using a layer of abstraction as the connective tissue for your best-of-breed tech stack will further enhance flexibility and the ability to quickly “hire and fire” tools.
These are day-one infrastructure considerations. If headless commerce is an afterthought, it will show down the line as you face issues with data velocity, eventual consistency, abstraction, scalability, tech stack responsiveness, and more.
This blog will explain the components of a headless-first infrastructure and how it’s rewriting the way eCommerce stores are built in order to delight customers and outperform competitors.
eCommerce microservices vs. monolithic systems
Everything in engineering is a tradeoff. Traditional monolithic eCommerce systems have ACID (atomicity, consistency, isolation, durability) guarantees that you will have to account for when you opt for a best-of-breed microservices approach, including any custom elements of your tech stack.
When you start to decouple your tech stack to adopt microservices, you’re favoring performance over consistency. Data consistency is essentially guaranteed in monolithic systems as they are one unified platform.
However, while monolithic systems may be consistent, there will be performance pain points such as the ability to scale efficiently and handle traffic spikes or the challenges of managing a massive codebase.
Data discrepancies are one of the largest risks associated with going headless. Failing to take this into account could result in eventual consistency issues, where there’s a lag time in data synchronicity between disparate systems. Bottlenecks that lead to eventual consistency are primarily caused by API data flow issues. This includes API rate limits, poorly designed APIs that force the developer to make multiple round trips to many upstream services, and slow API response times.
You can acknowledge these tradeoffs while implementing microservices and still strive to make those tradeoffs more tolerable.
In order to have success with microservices-driven headless architecture and make these tradeoffs more tolerable, you need to build safeguards into your infrastructure. For context, Nacelle’s headless commerce platform can bring lag time down to seconds or minutes, instead of hours or even days because it was built with a layer of abstraction and designed to induce high data velocity throughout your stack and between the backend and frontend.
Your infrastructure needs to be able to pull in objects at the volume you need, in the time that your headless implementation demands. Without this being a top priority in your build from day one, the mess that eventual consistency creates will be a primary pain point in your implementation.
Your engineering team could build a system that addresses these issues, but their time is likely better spent building a unique frontend or custom backend system that will differentiate your brand among eCommerce competitors. That’s why seeking a “build and buy” approach to headless commerce—buying a managed solution, with ability to build on top of it and customize—is usually the best option for enterprise-level, or close to enterprise-level, merchants who want to channel engineering resources elsewhere to set themselves apart from competitors.
Elastic technology in eCommerce infrastructure
Elastic technology will be an important aspect of your eCommerce infrastructure in order to support the full power of headless commerce. Elastic technology refers to resizable compute capacity in the cloud that’s designed to make web-scale cloud computing easier for developers.
In the context of headless commerce, an elastic infrastructure has the ability to scale horizontally in milliseconds to match the computing resources needed at any given time by adding more machines as needed. Traditional infrastructure scales vertically, which means adding more power (CPU, RAM) to an existing computer instead of adding more machines.
Most systems aren’t built on truly elastic technology. Monolithic systems aren’t built to scale horizontally, and as mentioned above, scaling vertically takes time—sometimes hours compared to the milliseconds offered by elastic, serverless technology.
In order to achieve your headless goals, the design of data and systems will be radically different than with a traditional monolith. Microservices and optimization of data indexing, altering, and rearranging data needs to fit the elastic, horizontally-scalable infrastructure.
Again, high data velocity is necessary for success here. The biggest problem with traditional infrastructure is that a high number of requests can slow servers down, meaning people can’t access the information they need. Shoppers end up waiting an unacceptable amount of time for the request to be filled. Because there’s a finite amount of resources to fill requests, demand is significantly higher than supply, and servers crash.
Architects implement rate limits to protect against this scenario, but as mentioned above, that can snowball into data flow bottlenecks and eventual consistency issues.
Also, Jamstack-based headless commerce frontend development architecture and functionality such as static site generation (SSG), and single page application architectures can be at odds with traditional monoliths.
For example, static site generation renders and saves HTML ahead of time so page requests from consumers don’t have to include a roundtrip server request. There are major benefits to site speed and other eCommerce performance, but traditional architecture built around rate limiting constraints fundamentally hinder static generation because it will limit the amount of requests and data that can be processed during SSG.
D2C fashion brand Something Navy is an excellent example of how profitable it can be when data flows without limitations, and sites are built to scale quickly to handle spikes in traffic. The brand crashed the Nordstrom website on four different occasions while collaborating, inspiring Something Navy to build their own eCommerce site. Their new site was built as a headless-first architecture, and sold $1 million worth of clothing in 30 minutes of going live, without a single hitch in performance. Today, that record has been reached within just seven minutes.
Source of truth in eCommerce infrastructure
A number of notable trends have emerged as technology companies shift from monolithic to microservice infrastructure. For example, it’s considered best practice for each microservice system to have its own database, which is notably different from traditional monolithic systems where one large database holds the source of truth for each service.
It’s therefore critical for microservices to be able to communicate effectively with one another. While APIs are great for delivering data to frontend applications, APIs aren’t the best tool for facilitating state (event) changes between microservices. The ideal communication system is fault tolerant, durable, and capable of replaying events to restore state for any given system.
Using an event stream as the source of truth is a great answer to this problem. This is an infrastructure-level process that logs every change in state as an event instead of writing and reading a database. This is an important feature for a best-of-breed microservices strategy because the event stream concept supports the decoupling that’s necessary to maximize microservice benefits and true headless functionality.
It’s important because you don’t have to call another server to get information or rely on another system’s data as fuel. And if the event stream is the source of truth, each microservice in your tech stack can take what it needs from the log. If a microservice goes down, it can replay the event stream and rebuild quickly and accurately.
In the context of headless-first, using the event stream as the source of truth and storing the stream in memory is conducive to the goals of headless commerce. This allows the merchant to receive real-time updates to changes in state from all upstream services. It also provides durability while offering a fast, efficient way to transport and query data in a headless environment.
Nacelle’s eCommerce infrastructure highlights
Nacelle was built specifically for headless commerce, and because it was intentional from day one, the architecture is conducive to extremely high data velocity which is necessary to support virtually all aspects of a headless build.
We use elastic technology that scales horizontally to ingest eCommerce data from a variety of sources. We deliver that eCommerce data via a robust API and an intuitive SDK. We don’t enforce rate limits, which means that your digital storefront will never exhaust its data source during the static generation process.
We also use the event stream as our source of truth, allowing us to store data in a way that doesn't take long to query. Because of the way our infrastructure is built, we’re able to act as a data layer which opens up doors to tech stack independence and flexibility, without sacrificing connectivity.
Our headless commerce platform is for merchants who want to “build and buy” their headless solution. They’re interested in a system with a solid headless-first infrastructure and managed service, but still want the ability to customize it to their unique needs.
Ready to see Nacelle in action? Start a free trial today.
