Reference build 04 · Retail
Headless Commerce
Prerendered catalogue with edge cart state and inventory reservation that prevents oversell.
What we'd be solving.
A multi-channel retailer has a storefront that is slow on mobile and oversells during sale events. Catalogue pages are rendered per request, and stock is synced between channels on a schedule.
The approach
Four decisions that shape everything else.
- 01
Static catalogue, revalidated on change
Product pages are prerendered and invalidated by webhook when the catalogue updates. The common path becomes a CDN hit instead of a database query.
- 02
Cart state at the edge
Per-session cart and pricing run in an edge runtime near the user. Only the genuinely dynamic part pays a latency cost.
- 03
Reserve stock at add-to-cart
A short-lived reservation with automatic expiry, held centrally. Oversell comes from treating inventory as eventually consistent across channels; reservation removes the window.
- 04
Rehearse the peak
Sale events are known dates. Load is tested against the real architecture beforehand, so capacity is a decision rather than a discovery.
Headless Commerce, in one picture.
- 01BuildCatalogue pages prerendered, not rendered per request
- 02CDNStatic pages revalidated when the catalogue changes
- 03Edge cartCart state held at the edge, close to the shopper
Deliberately off the main path
- Stock reservationTaken at add-to-cart against Postgres, so two shoppers cannot both be sold the last unit.branches from 03 Edge cart
What we rejected
The alternatives, and why they lost.
Anyone can list the technology they chose. What tells you whether a team can be trusted with your system is whether they can explain what they didn't choose.
| Option rejected | Why it lost |
|---|---|
| Server-rendering catalogue pages per request | Pays a database round trip for content that changes a few times a day, and it is the direct cause of the mobile slowness. |
| Scheduled inventory sync between channels | The sync interval is precisely the oversell window. Shortening it reduces the symptom without removing the cause. |
| A single monolithic commerce platform | Simpler initially, but it couples storefront performance to a release cycle the retailer does not control. |
Other reference builds
Keep reading.
Start here
Tell us the problem.
We'll be honest about the fit.
A first conversation costs nothing and is useful even if you go elsewhere — you'll leave with an architecture opinion and a realistic sense of scope.
- Reply within 24 hours
- No sales sequence