Notes from the Commerce Stack

If you've worked in e-commerce for the past five years, you've watched a tectonic shift happen in real time. The monolithic platforms that once dominated the space — the all-in-one solutions that handled everything from inventory to checkout to email — are being gradually unbundled into specialized services.

This isn't just a technology trend. It reflects a deeper change in how businesses think about their digital infrastructure.

The composable thesis

The argument for composable commerce is straightforward: no single vendor can be best-in-class at everything. A platform that handles product information management, search, checkout, content, loyalty, and analytics is spreading itself across too many problem domains. At some point, the compromises become visible to customers.

Composable architecture says: pick the best tool for each job, and connect them through APIs. Your search might come from Algolia, your content from a headless CMS, your checkout from a specialized payments provider, and your product data from a PIM built for your specific catalog complexity.

Where it gets complicated

The theory is clean. The practice is messy. Every API integration is a potential point of failure. Every vendor relationship is a contract to manage. Every data flow between systems needs to be monitored, versioned, and maintained.

I've seen teams adopt composable architecture and end up spending more time on integration plumbing than on the customer experiences they were supposed to be improving. The stack becomes the product, and the actual product suffers.

The middle path

The most effective commerce teams I've worked with take a pragmatic approach. They don't go fully composable on day one. Instead, they identify the one or two capabilities where their current platform is genuinely holding them back, and they swap those out first.

Maybe search is the bottleneck — customers can't find what they're looking for, and the built-in search is barely functional. So you integrate a dedicated search provider and leave everything else alone. You learn how to manage an API integration in a low-risk context before you attempt a full-stack decomposition.

What matters more than architecture

At the end of the day, the best commerce stack is the one that lets your team ship improvements to the customer experience quickly and reliably. If your monolith does that, keep it. If a fully composable stack does that, great. Most teams land somewhere in between, and that's fine.

Architecture is a means, not an end. The customers browsing your site don't care whether your checkout is a microservice or a module in a monolith. They care whether it works.