What modern e-commerce architecture actually looks like
The storefront is the visible 20%. The rest is catalog, stock, payments, fulfilment and finance agreeing with each other.
Trillune Engineering7 min read
Commerce projects are often scoped as 'a new website'. Then launch week reveals that stock is wrong, refunds don't reach the accounting system and the warehouse is printing orders from email. The storefront was never the hard part.
Think in capabilities, not pages
A useful way to map a commerce operation is by capability, each with a clear owner:
- Catalog — product data, variants, media, pricing rules
- Inventory — stock per location, reservations, availability
- Checkout — cart, tax, shipping options, payment
- Orders — lifecycle, routing, fulfilment, returns
- Customers — accounts, addresses, consent, loyalty
- Finance — settlement, refunds, reconciliation, reporting
Some of these will live in a commerce platform, some in an ERP, some in specialist services. The architecture is the set of decisions about where each lives and how they talk.
Headless when it earns its place
Separating the storefront from the commerce engine gives you freedom over performance, design and content — and costs you some things the platform previously did for free. It's the right call when speed, custom experiences or multiple front-ends matter. It isn't automatically better.
Events connect the operation
Orders placed, payments captured, stock adjusted, shipments dispatched: modeling these as events that other systems subscribe to keeps the storefront fast and lets fulfilment, ERP and analytics react independently. It also creates a natural audit trail.
Modern commerce architecture isn't a stack. It's a clear map of responsibilities and reliable connections between them.