Key terms to know in headless commerce

6 min read
November 8, 2021

As headless commerce becomes more mainstream, new terminology related to headless has emerged, and old terminology has become a little watered down—even skewed in some cases. While you and your team explore headless as a viable technology solution for your brand, you’re going to encounter these terms, new and old.

Some terms are interchangeable, some have subtle nuances, and others will be more familiar to certain audiences such as technical teams. This blog will define and explain some of these commonly used industry terms.

The old guard: headless commerce terms

Before we dive into the new terms buzzing around headless commerce conversations, let’s revisit some of the tried-and-true foundational concepts.

Headless commerce

Headless commerce is an eCommerce architecture where the backend systems are decoupled from the frontend presentation layer of a website, with APIs sending data back and forth. A robust headless commerce solution will help with the connection between both the backend and frontend systems, and the data transfer between the two. This allows the eCommerce team to build out a frontend that is fully customizable, lightning fast, mobile-first, and has the ability to handle large spikes in traffic and enable storytelling capabilities. An engineering-driven solution can also improve developer workflows significantly.

It’s important to define headless commerce because not all solutions are created equal, and some blur the line of what it truly means to be headless, or decoupled, by forcing merchants to use complementary backend systems to access headless functionality. Teams evaluating headless commerce solutions need to be vigilant about the definition and ethos of headless when critically analyzing various systems.

Separation of concerns

Separation of concerns is an engineering design principle and best practice that refers to breaking down a computer system into distinct sections so each section can excel at its specialized job. It’s a conceptual precursor to several of the technical commerce strategies we’re excited about like composable commerce. This principle encourages flexibility, performance, freedom, and velocity. Many of the revolutionary products transforming the eCommerce landscape today serve as a separation of concerns on the macro level, and can unlock value measured in the billions.

Technical debt

Tech debt is a general technology concept that uses “debt” as a metaphor for the costly side effects—be it financial, or time and resource-based—of making hurried or ineffective software decisions that incur codebase deficiencies, or cruft. It will usually compound over time, and ultimately be extremely expensive and often risky to rectify. In the context of headless commerce, we talk about technical debt in terms of the headless solution you choose. Miscalculations of your brand’s headless commerce needs now, and in the future, could incur significant levels of technical debt because choosing a headless commerce solution is a deep, infrastructure-level business decision.

Further Reading

Monolithic architecture

Monolithic architecture, or traditional architecture, is important to fundamentally understand because it juxtaposes so many of the new concepts and approaches to eCommerce technology. A monolithic platform means different eCommerce components are combined in a single program from a single platform. When you hear “all in one” or “end-to-end,” think monolithic. In the context of eCommerce and headless commerce solutions, monolithic solutions are ACID-compliant, meaning they offer near-guarantees around atomicity, consistency, isolation, and durability (ACID). Adopting a different type of architecture emphasizes different characteristics such as site performance, and there will be a tradeoff. That said, good technology solutions will make tradeoffs tolerable.

Further Reading

Vertical and horizontal scaling

Scaling refers to how computing power is added to your eCommerce store when needed.

Vertical Scaling - Understanding what it means to “scale vertically” is also a precursor to understanding modern infrastructure and innovative headless commerce architecture that scales horizontally. By scaling vertically, or scaling up, you increase the capacity of a single machine and its throughput. Data lives on a single node, and you add more resources to that node by adding additional central processing units (CPUs) and random-access memory (RAM) to account for increased demand.

Horizontal Scaling - Horizontal scaling, or scaling out, adds more instances of machines to the resource pool rather than adding resources. This allows you to scale your data with more resources than you can add with vertical scaling and it’s often talked about when discussing elastic technology. Engineers like the horizontal approach because it allows them to respond in milliseconds to traffic spikes without sacrificing site performance. Monolithic systems aren’t built to scale horizontally and scaling vertically takes time—sometimes hours, compared to the milliseconds offered by elastic, serverless technology and horizontal scaling.

Further Reading

The new guard: headless commerce terms

While many of these terms are relatively new, they’re often rooted in principles and practices that might be familiar. That said, these terms embrace the spirit of the eCommerce revolution being seen in commerce technology currently.

Composable commerce

A term coined by Gartner in a June 2020 report, composable commerce encompasses the ideology of separation of concerns, and solidifies what it means to embrace a “best-of-breed” strategy. It refers to merchants assembling a customized tech stack consisting of “best-of-breed” solutions, meaning each off-the-shelf or custom-built tool in the stack is the best available in its respective area. The pillars of composable commerce are:

  • Modular - Each component of your tech stack (CRM, PIM, CMS, OMS, etc.) is independent, and can be deployed and interchanged without significantly impacting the rest of your technology ecosystem.

  • Open - There’s no vendor lock-in because applications seamlessly integrate with each other, despite coming from different vendors.

  • Flexible - Composable commerce allows merchants to curate a tech stack that’s completely tailored to what they need to best serve their customers. Every brand and business is different, and their tech stack should reflect that.

  • Business-centric - Compostable commerce enables brands to be agile and responsive to the changing eCommerce landscape and the accompanying business requirements. You can add, subtract, and change tools as needed with little to no impact on the rest of your tech stack. It also allows merchants to introduce custom elements to their tech stack and create a stack of best-of-breed tools—of off-the-shelf and custom systems—to help with differentiation and customer satisfaction.

  • Scalability/Adaptability - As consumer and business needs inevitably change, a composable commerce approach will allow merchants to respond quickly, with relative ease.

Further Reading

Distributed systems

Distributed systems are the individual systems that make up a composable tech stack. In the spirit of “best-of-breed,” these solutions are typically the best tool in their respective area and can be an off-the-shelf third-party option, or a custom-built tool. The right headless commerce solution will have a data layer that ingests data from these systems and connects them. This helps to prevent hard-coding systems together and “spaghetti code.” While the systems on the backend are distributed, they become unified for the shopper on the frontend.

Further Reading

Eventual consistency

Merchants in favor of a composable tech stack will forgo the near-guaranteed data consistency across their operation that a monolithic solution provides. But by putting performance and best-in-class tools first, engineers inevitably introduce the issue of eventual consistency to their webstore. Eventual consistency implies there’s a dataset discrepancy between two systems (such as your PIM and frontend) that should be in sync. These two systems might be out of sync at a given time, but eventually, the one lagging will catch up and accurately reflect the other. The longer it takes for a lagging system to catch up to the freshness of the other, the more likely it is for merchandising havoc to ensue, including sales losses or inaccurate information being displayed to shoppers. The right headless commerce solution will make eventual consistency more tolerable.

Further Reading

Interoperability

Interoperability is the ability for distributed systems in different domains to communicate with one another and exchange data effectively. For example, the ability to propagate data coming from your PIM to all the other systems that need to use that data, such as the checkout.

Further Reading

Data layer/abstraction layer

This is a layer in your headless commerce architecture that improves organization and unlocks the maximum potential of a composable commerce strategy. An abstraction layer acts as the connective tissue between your frontend and your distributed systems on the backend. It sits in between your applications and data, unifies syntax, and acts as an intermediary that fetches data for you. We usually say “data layer” when talking about the static site process and “abstraction layer” when talking about headless architecture as a whole, but the terms can be used interchangeably.

Further Reading

How Nacelle talks about headless commerce

Nacelle is a headless commerce platform that enables composable commerce. Our architecture helps merchants achieve true backend-frontend separation, but we also take that ethos a step further by enabling separation throughout the tools on the backend. This helps merchants avoid vendor lock-in and technical debt while keeping the tools and platforms they love such as Shopify Plus, third-party applications, or custom systems.

The Nacelle architecture uses an elastic core and scales horizontally, allowing Nacelle-powered webstores to scale in milliseconds and handle large spikes in traffic. Our solution acts as the data layer, and is built to make engineering tradeoffs like eventual consistency tolerable, so merchants don’t have to make significant sacrifices while moving away from monolithic architecture to composability.

Next Read: Reimagining the Way eCommerce Stores are Built

Receive our latest blogs directly into your inbox