Headless Ecommerce: The Architecture, and the Bill Attached to It

Headless ecommerce means the storefront your customers see is a separate application from the commerce engine holding products, carts, and orders, connected over APIs. The architecture is sound. What the vendor guides leave out is that you now own the storefront — building it, deploying it, caching it, and keeping it up during a sale.

Every explanation of headless commerce is published by a company selling a piece of it, which makes them consistent about the benefits and quiet about the responsibility transfer. That transfer is the actual decision. Going headless is choosing to run a web application instead of configuring a hosted platform, and whether that is a good trade depends almost entirely on whether you have someone to run it.

Table of contents

• What headless means structurally
• What you take on
• Caching, which is where headless is won or lost
• The hosting shape it needs
• When headless is worth it
• If you do it, do these
• How this fits the rest of the stack
• FAQ

What headless means structurally

A traditional commerce platform is one system. It stores the products, renders the pages, handles the cart, takes payment, and manages orders. You pick a theme and configure it.

Headless separates the presentation layer from everything else. The commerce engine keeps the catalogue, pricing, cart logic, checkout, inventory, and orders, and exposes them over an API. The storefront is an application you build — typically in a JavaScript framework — that calls those APIs and renders whatever you want.

The term composable extends the idea: instead of one engine, you assemble several services — a commerce engine, a content management system, a search provider, a payment processor, a personalisation service — each connected by API.

The claimed benefits are genuine ones.

• Complete control over the customer experience, since the frontend is your code rather than a theme within someone’s template system.
• The same backend serving a website, a mobile app, an in-store display, and a marketplace integration.
• Performance, because you control exactly what loads and when rather than inheriting a theme’s assumptions.
• Freedom to replace one component without rebuilding everything, at least in principle.
• Content and commerce combined, so editorial pages and product pages come from systems each suited to their job.

None of that is marketing. It is all real, and each of it has a cost on the other side of the ledger.

What you take on

The part the vendor pages skip. Going headless means the storefront is an application you own, and applications need owning.

• You build it. Product listings, filtering, search results, product detail, cart, checkout flow, account pages, order history. A hosted theme provides these; now you write them.
• You deploy it. A build pipeline, environments, a release process, and a rollback path.
• You cache it. This is the big one and it has its own section below.
• You keep it up. During a sale, during a campaign, during whatever traffic arrives. The engine scales because it is somebody’s product. Your storefront scales because you made it scale.
• You maintain it. Framework upgrades, dependency updates, security patches, and the API changes the commerce engine ships.
• You handle SEO. A hosted platform does a reasonable job by default. A custom storefront does whatever you built — which can be better and is frequently worse until someone does the work.
• You own accessibility. Same reasoning.

That is a development team’s worth of ongoing work, not a project with an end date. The businesses for which headless works well have that team. The ones for which it goes badly bought the architecture and expected it to behave like a platform.

Caching, which is where headless is won or lost

The single most important technical decision in a headless build, and the one that determines whether the site is faster or slower than the platform it replaced.

A naive headless storefront makes several API calls per page render. If those happen on every request, the site is slower than a monolithic platform, because you have added a network hop where previously there was a function call. People are frequently surprised by this: they went headless for performance and shipped something slower.

The layers that fix it:

• Static generation for anything stable. Category pages, content pages, and product pages for a catalogue that changes daily can be prerendered at build time and served as files.
• Incremental regeneration for larger catalogues, where pages are generated on first request and cached, then refreshed on a schedule or on a webhook from the engine.
• Edge or CDN caching in front of everything, with a considered cache key. Anonymous visitors should hit cache; logged-in ones should not.
• Client-side fetching for the genuinely dynamic parts — live stock, personalised pricing, cart contents — so the page shell is cached and only the volatile fragments are fetched.
• Cache invalidation driven by webhooks from the commerce engine, so a price change propagates in seconds rather than waiting for a TTL.

That last point is the one that requires real design. Stale prices are worse than slow pages — showing a price you will not honour is a customer service problem and in some jurisdictions a legal one. Getting invalidation right is a genuine engineering task, and it is the part that separates a headless build that works from one that generates incidents.

The architectural rule of thumb: cache the shell aggressively and fetch the volatile parts separately. A product page whose layout, description, and images are cached while stock and price are fetched client-side is both fast and correct.

The hosting shape it needs

A headless storefront has specific infrastructure requirements, and they are different from what a hosted platform needed because previously there was none.

A build pipeline. Every content or catalogue change that triggers a rebuild needs a build to run, and on a large catalogue those builds are not fast. If you are prerendering ten thousand product pages, build time becomes an operational concern rather than a footnote.

A runtime for anything server-rendered. Either a Node process or a serverless deployment, and the choice matters for cold starts during quiet periods and for how you connect to anything that needs a persistent connection.

Capacity for the peak. This is the requirement that gets underestimated. Ecommerce traffic is not flat — it is a normal week and then a day when everything happens at once. A storefront sized for the normal week fails on the day that matters, and that day is when the revenue is.

Autoscaling between a floor and a ceiling handles this: scale up on load, back down afterwards, with an upper bound you chose so the bill has a known maximum. Configuring that before a promotion rather than during one is the difference between a good day and a post-mortem.

Webhook endpoints. The commerce engine, the payment processor, and any fulfilment integration all send webhooks, and those endpoints have to stay responsive while the front end is busy — which is precisely when they are most likely to be starved of capacity.

A CDN with real cache control. Headers, redirects, and cache rules should be part of the project configuration and ship with the deploy rather than being clicked into a dashboard nobody has documented.

When headless is worth it

Honestly, because the answer is not always yes and the industry writing about it has an interest in the answer being yes.

It is worth it when: the customer experience is genuinely a differentiator and the platform theme is holding you back; you sell through several channels sharing one catalogue; you have a content-heavy business where editorial and commerce need to interleave; you have real performance requirements a theme cannot meet; or your business logic is unusual enough that no platform’s model fits.

It is not worth it when: the store works and the motivation is that headless sounds modern; you have no in-house development capability and would be dependent on an agency indefinitely; the catalogue is small and the experience conventional; or the actual problem is a slow theme, which is far cheaper to fix than to replace with an architecture.

That last case is common enough to name. A great deal of headless migration is undertaken to solve page speed, and a great deal of page speed on hosted platforms is oversized images, too many apps, and render-blocking scripts. Fixing those takes a week. Going headless takes months and introduces performance problems of its own if the caching is not right.

The middle path, which suits many businesses, is to stay on the platform and replace only the parts that hurt — a custom landing page experience, a faster search, a separate content site — rather than rebuilding the whole storefront.

If you do it, do these

1. Design the caching strategy before writing the storefront, not after it is slow. Decide what is static, what is regenerated, and what is fetched live.
2. Build invalidation on webhooks from the engine, so prices and stock are never stale in a way that matters.
3. Load-test before the first peak, at the volume you expect on your busiest day, not at typical traffic.
4. Keep the checkout on the engine’s hosted flow initially. Payment and checkout are where the regulatory and fraud complexity lives, and building your own is the highest-risk part of the project.
5. Instrument everything. Storefront errors, API latency, cache hit ratio, and webhook failures should all be visible.
6. Plan the SEO work explicitly — structured data, canonical URLs, redirects from the old URL structure, sitemaps. None of it comes free.
7. Set autoscaling bounds before a promotion rather than during it.

The redirect map deserves particular emphasis. Replacing a storefront usually changes the URL structure, and a migration that does not map every old product and category URL to its new equivalent discards the search presence the business already had. That is the most expensive avoidable mistake in a replatform, and it is invisible until traffic drops the following month.

How this fits the rest of the stack

Headless commerce buys you control over the experience and costs you a web application to build, deploy, cache, and keep up during your busiest hour. That is a good trade for businesses with the team and a poor one for businesses who wanted a faster theme. If you do go ahead, the caching design and the peak-capacity plan are the two decisions that determine whether it works. The RunxBuild hosting calculator prices the storefront service, the database, and the bandwidth separately, with autoscaling between plans you choose so the busiest day has a known ceiling.

Useful related references:

• Ecommerce Websites: The Parts You Pay For Every Month
• PDF Generator API: Buy, Build, or Run Headless Chrome Yourself
• Next.js CMS: Choosing Between Git, Headless, and Something You Already Have
• Services on RunxBuild

FAQ

What is headless ecommerce?

An architecture where the storefront customers see is a separate application from the commerce engine holding products, carts, and orders, connected over APIs. It gives you full control of the experience and means the storefront is now software you build, deploy, cache, and maintain rather than a theme you configure.

Is headless commerce faster than a traditional platform?

Only if the caching is designed properly. A naive headless storefront makes several API calls per render and is slower than a monolith, because a network hop replaced a function call. Done well — static generation, edge caching, and volatile data fetched separately — it is faster. The caching strategy is what decides it.

Is headless worth it for a small store?

Usually not. If the catalogue is modest and the experience conventional, a hosted platform does more for you than you will replace. Much headless migration is undertaken to fix page speed, and page speed on hosted platforms is usually oversized images, too many apps, and blocking scripts — a week of work rather than a months-long replatform.

Does headless ecommerce hurt SEO?

It can, because everything a hosted platform did by default is now yours: structured data, canonical URLs, sitemaps, and server-rendered content. The most damaging and most avoidable mistake is changing the URL structure without mapping every old product and category URL to its new equivalent, which discards the search presence the business already had.

What hosting does a headless storefront need?

A build pipeline that can handle rebuilds at your catalogue size, a runtime for server-rendered pages, a CDN with real cache control, responsive webhook endpoints for the engine and payment provider, and enough capacity for the peak rather than the average. Autoscaling between a floor and a ceiling plan handles the peak with a known upper bound on cost.