Microservices commerce

Microservices commerce is an architectural pattern where an ecommerce platform is built as a set of small, independent services rather than a single application. Each service owns one business capability. Catalog is a service. Cart is a service. Checkout is a service. Search is a service. Order management is a service. Each service has its own codebase, its own database, and its own deployment cycle. They communicate through APIs. ## Why microservices matter for commerce A monolithic commerce platform bundles everything into one deployable unit. Changing the checkout logic requires deploying the whole platform. Scaling the search index means scaling the entire stack. Upgrading the catalog engine means upgrading everything. This is slow and expensive at enterprise scale. Microservices trade that constraint for operational complexity. Each service can be developed by a separate team, scaled independently, and replaced without touching the rest. When search traffic spikes on Black Friday, the search service scales up while the account service stays quiet. When the catalog engine needs an upgrade, the rest of the platform keeps running. ## Microservices as the M in MACH MACH uses microservices as its M. The MACH Alliance treats microservices as one of the four properties a modern platform should have. In practice, most MACH-certified platforms are built on a microservices architecture internally, whether or not that architecture is visible to the buyer. The microservices label is a technical description of how the platform is built, not a functional description of what it does. Two platforms can both be microservices-based and still feel very different to merchants because the surface APIs, editor experiences, and integration paths differ. ## What microservices commerce is not Not every service is a microservice. If a platform has three or four separate services, that is a service-oriented architecture, not microservices. The distinction is fuzzy but real: microservices imply many small services, each with a narrow responsibility, deployed independently. A platform that splits its monolith in half and calls the result microservices is stretching the term. Microservices are also not automatically better for every merchant. A small merchant running a straightforward D2C storefront rarely benefits from a microservices platform. The operational overhead of running many services outweighs the benefits when the transaction volume is modest. Microservices commerce shines at enterprise scale, in complex B2B scenarios, and in operations that need to swap components without full replatforming. ## How Frntkey relates Frntkey does not run its own commerce microservices. It is a frontend that consumes whatever commerce backend the merchant has. When paired with Norce, Frntkey consumes Norce's APIs regardless of how Norce is architected internally. When paired with commercetools or another MACH platform, Frntkey consumes those APIs the same way. The frontend does not need to know or care about the backend's internal architecture. What matters is whether the APIs are complete, stable, and fast, which is what API-first commerce is really about. ## Related terms MACH architecture · Composable commerce · API-first commerce · Headless commerce