MACH Architecture or a Modular Monolith: How to Decide

Architecture discussions in digital commerce and SaaS often present a binary choice: stay on a legacy monolith or move to MACH. In practice the decision is wider. Many teams get most of the benefits they want — faster change, clear ownership, room to grow — from a well-structured modular monolith, and reach for distributed, composable architecture only where it solves a specific problem.

This guide explains both approaches, compares them on the factors that usually decide success, and gives a scorecard and an evolution path you can adapt.

What MACH means

MACH is an acronym promoted by the MACH Alliance, an industry body founded in 2020 by commercetools, Contentstack, EPAM Systems and Valtech. The letters stand for:

• Microservices-based: the system is built from independent services, each responsible for one business capability, deployed and scaled separately.
• API-first: capabilities are exposed through well-defined APIs designed before implementation, so components can be combined and replaced.
• Cloud-native SaaS: components run as cloud services — often vendor-operated SaaS — that scale elastically and are updated by their providers.
• Headless: the presentation layer is decoupled from back-end logic, so one back end can serve websites, mobile apps, kiosks and other channels.

MACH is closely associated with composable commerce: assembling commerce, content, search, payments and other capabilities from specialised vendors rather than one suite. MACH describes the technical principles; composable commerce describes the business approach of choosing and combining components.

What a modular monolith means

A modular monolith is a single deployable application divided into modules that each own a business capability. The difference from a traditional monolith is discipline:

• Clear boundaries: each module — orders, billing, catalogue, accounts — has a defined responsibility.
• Public interfaces: modules talk to each other only through explicit public APIs inside the codebase, not by reaching into each other’s internals.
• Data ownership: each module owns its tables. Other modules do not query them directly.
• Enforced rules: boundaries are checked automatically, so they do not erode under deadline pressure.

Shopify is a well-documented example. In a 2019 engineering article, Kirsten Westeinde described how Shopify — one of the largest Ruby on Rails codebases, worked on by more than a thousand developers — chose to componentise its monolith rather than split it into microservices. The team reorganised code by business domain, gave each component a public API and exclusive ownership of its data, and built tooling to measure and flag boundary violations. The article notes the decoupling made it possible to replace a legacy tax engine, a change that would have been very hard before.

Martin Fowler’s “Monolith First” essay (2015) makes a related argument: most successful microservice systems he observed started as monoliths that were later broken up, partly because good service boundaries are hard to see at the start.

How the two approaches differ in practice

When MACH fits

MACH and composable architecture make sense when one or more of these conditions are true:

• Several teams must release independently. If four or more teams are blocked by a shared release train, separating deployments can remove real friction.
• Many channels share one back end. A brand serving web, mobile apps, marketplaces, in-store screens and partner APIs benefits from a headless, API-first core.
• Best-of-breed components are a business priority. You want specialist search, content and commerce engines and are prepared to integrate and govern them.
• Capabilities have very different scaling patterns. Search traffic during a sale, for example, may need to scale independently of order management.
• You have operations maturity. Automated infrastructure, observability, incident response and API governance already exist or are budgeted.

When a modular monolith fits

• The team is small or medium-sized. One or two product teams usually move faster with one deployable application.
• The domain is still changing. If you are still discovering how orders, subscriptions or pricing should work, boundaries will move. Moving code inside a codebase is far cheaper than renegotiating service contracts.
• Consistency matters. Workflows that must update several capabilities atomically — orders, inventory and payments — are simpler in one process and database.
• Operations capacity is limited. You cannot yet run distributed tracing, many pipelines and on-call rotations for dozens of services.
• Budget is constrained. SaaS subscriptions for every capability, plus integration work, can exceed the cost of building and running a focused application.

The costs that MACH articles often leave out

Composable architecture is often justified with “lower total cost of ownership over time”. That can be true, but only when the costs below are budgeted honestly:

Designing a modular monolith that can evolve

If you choose a modular monolith, design it so that extraction remains possible:

1. Organise code by business domain, not by technical layer. Folders such as orders, billing and catalogue are easier to reason about than models, views and controllers.
2. Define a public interface per module and make everything else private. Calls between modules go through that interface.
3. Give each module its own tables and forbid cross-module queries. If one module needs another’s data, it asks through the interface or subscribes to events.
4. Enforce boundaries in CI. Use dependency rules or architecture tests that fail the build when a module reaches into another’s internals.
5. Publish domain events for changes other modules care about, such as “order placed” or “invoice paid”. This prepares for asynchronous integration later.
6. Keep the front end separate where multiple channels are likely. A headless API layer on top of a modular monolith gives you channel flexibility without distributing the back end.

An evolution path with explicit triggers

Rather than choosing a final architecture on day one, define the conditions that would justify the next step.

Extraction should follow the parallel-change approach: build the new service alongside the module, route traffic gradually and remove the old path only when the new one is proven. Our guide to planning a zero-downtime migration covers the data side of such moves.

From a tangled monolith to a modular one

Many teams reading about MACH start from a monolith whose problems are real: slow tests, fragile releases, unclear ownership. Before deciding to distribute the system, it is usually worth making the monolith modular. The work is valuable in either future.

1. Map business capabilities. List the capabilities the system provides — catalogue, pricing, orders, payments, customers, reporting — and the teams or people who understand each.
2. Find the seams. Use code analysis and change history to see which files change together. Files that always change together probably belong in the same module.
3. Create module folders and public interfaces. Move code gradually; start with the capability that changes most often or causes most incidents.
4. Separate data ownership. Assign tables to modules and replace cross-module queries with calls through interfaces or with events.
5. Add automated boundary checks. Fail builds that introduce new violations, and track the number of remaining violations over time.
6. Improve tests per module. Faster, focused tests are one of the earliest benefits teams notice.
7. Revisit the architecture decision. With clear modules, you can see whether any module truly needs independent deployment.

Team topology and ownership

Architecture and organisation influence each other: systems tend to mirror the communication structure of the teams that build them. Before adopting MACH, ask:

• Who will own each service or vendor integration, including on-call responsibility?
• Who owns the contracts between components, and how are breaking changes negotiated?
• Who owns the end-to-end customer journey when it spans several vendors and services?

If these owners do not exist, distributed architecture will create gaps where incidents fall between teams. A modular monolith with clear module owners is often a better fit until the organisation grows.

A worked example

A business-to-business ordering platform has two product teams, serves a web portal and a mobile app, integrates with an ERP and a payment provider, and has a monolith with frequent regressions. The team scores itself on the scorecard below: product teams 2, independent releases 2, channels 3, domain stability 3, operations maturity 2, third-party SaaS strategy 2, differential scaling 2, budget 2 — a total of 18 out of 40.

The decision: modularise the monolith, put a headless API in front of it for the web portal and mobile app, and use a managed search service for the catalogue because search quality is a differentiator and building it in-house would be costly. Revisit extracting the pricing module as a service in twelve months if pricing changes continue to dominate the release calendar. This illustrative outcome captures most of the benefit teams expect from MACH — channel flexibility and faster change — without taking on the full operational cost.

An architecture scorecard

Score each factor from 1 to 5 for your situation. Higher totals favour MACH; lower totals favour a modular monolith.

A total around the middle often points to a modular monolith with a headless API and one or two extracted services or SaaS components where they clearly add value.

Common mistakes

• Choosing microservices to fix a messy codebase. Distribution does not create good boundaries; it makes bad boundaries more expensive.
• Splitting by technical layer. Services named “database service” or “notification service for everything” create chatty, fragile systems.
• Sharing a database between services. This keeps the coupling of a monolith while adding the complexity of distribution.
• Underestimating integration. Composable architecture shifts effort from building features to connecting and governing components.
• Letting monolith boundaries erode. Without automated checks, a modular monolith slowly returns to a tangled one.

Frequently asked questions

Is MACH only for e-commerce?

The term is most common in commerce and content platforms, but the principles apply to any product that serves many channels or wants to combine specialised services.

Can a modular monolith be headless?

Yes. A modular monolith can expose APIs to separate web and mobile front ends. Headless is about the front end; modularity is about how the back end is organised.

How long does it take to move from a monolith to MACH?

It depends on the size of the system and how many capabilities move. Most successful migrations are incremental and take many months, extracting one capability at a time.

What should we do first if our current monolith is tangled?

Map business domains, introduce module boundaries and automated checks, and separate data ownership. That work is valuable whether you later extract services or not.