Break free from your commerce monolith with microservices architecture

A monolith is often the right answer at early scale. It is simpler to deploy, debug, and reason about when a single team owns the whole codebase. Microservices make sense when specific pain points appear: deployments require full-team coordination, one domain's traffic spikes affect the whole platform, or you need different teams to ship independently without stepping on each other.

If none of those problems are real yet, the operational overhead of distributed services — network latency, distributed tracing, Saga complexity — is cost without benefit. We help teams make this assessment honestly before recommending a migration.

Microservices shift complexity from the codebase into operations. Your team needs confidence in containerisation, CI/CD pipelines, observability tooling, and on-call practices before taking on a distributed architecture. Teams that struggle to deploy a monolith reliably will struggle more with ten services.

We typically recommend starting with a platform engineering investment — standardising deployment pipelines and observability — before extracting the first service. This means the infrastructure is ready when the first microservice goes to production.

MACH (Microservices, API-first, Cloud-native, Headless) is a vendor and architecture philosophy that microservices make possible. Composable commerce takes this further by assembling best-of-breed SaaS vendors — a specialist search provider, a dedicated promotions engine, a headless CMS — each filling one bounded context.

Microservices architecture is the technical foundation; MACH and composable commerce are the procurement and product strategy built on top of it. See our for how vendor selection maps to service boundaries.

Each service owns its schema and is the single source of truth for its domain. Other services query it via API or consume its events — they never read its database directly. This creates eventual consistency: the order service may hold a cached copy of a product name, which could briefly differ from the catalogue service's current value.

For most commerce workflows, eventual consistency is acceptable. For financial transactions — payment capture, stock reservation — we use the Saga pattern with compensating transactions to guarantee that a failed step rolls back cleanly across services.

It depends on the size of the monolith, the quality of existing test coverage, and how many teams are involved. A first service extraction — typically notifications or user/auth — can be in production within a few weeks. Extracting a high-risk domain such as order management or checkout takes longer because of Saga design, data migration, and traffic cutover planning.

Full migrations are measured in quarters, not weeks. We plan the sequence to deliver production value at each step so the business is not waiting for a complete rewrite before seeing benefit.

The table below summarises the core trade-offs engineering teams face:

• Deployment complexity: Monolith — one pipeline, one artefact. Microservices — one pipeline per service, requires container orchestration and service discovery.
• Fault isolation: Monolith — one bug can take down the whole platform. Microservices — a failing promotions service does not block checkout if circuit breakers are in place.
• Team scaling: Monolith — coordination overhead grows with team size. Microservices — teams own services independently, reducing merge conflicts and release dependencies.
• Performance overhead: Monolith — in-process calls are fast. Microservices — network hops add latency; gRPC and async messaging mitigate this.
• Time to market: Monolith — faster initially. Microservices — faster per team once the platform is established, because teams ship without waiting for others.