MACH: a measured take

MACH (Microservices, API-first, Cloud-native, Headless) is the architecture industry buzzword of the last five years. The MACH Alliance has done a good job of evangelising the pattern, particularly for ecommerce. For the work we do — governments, regulators, public-facing platforms — MACH is sometimes the right call and sometimes architectural fashion. Here's how we tell which.

What's actually new in MACH

Not much. Microservices have been around for 15 years. APIs have been around since the late 90s. Cloud-native is just "runs on cloud infrastructure", which is what almost everyone does. Headless means decoupling the content store from the frontend, which is a 2010s pattern at this point.

What MACH does usefully is package these into a coherent recommendation: stop building monolithic vendor platforms, compose your stack from best-of-breed services connected by APIs. That's a defensible architectural position when the trade-offs work for you.

Where MACH wins

Multi-frontend organisations: a single ecommerce backend serving a website, a mobile app, a kiosk system, a third-party marketplace integration. Each frontend has different requirements and timelines; decoupling them from the backend lets each team move independently.

Best-of-breed needs that don't exist in any monolithic product. Search via Algolia. Translations via Crowdin. CDN via Cloudflare. Each replaceable, each specialised.

Organisations large enough to absorb the integration complexity. MACH increases the total number of moving parts by an order of magnitude versus a monolith. Big organisations have integration teams who can absorb that. Small organisations don't.

Where MACH loses

Small editorial teams running a single website. The Headless half of MACH is genuinely useful here, but Microservices and API-first add accidental complexity. A small council doesn't need its CMS, search, and personalisation as separate services billed separately and integrated by a contractor. They need one well-built CMS.

Workflow-heavy publishing. MACH separates content management from content delivery, but most MACH content management systems (e.g., the proprietary headless CMSes) have weaker workflow than Plone or Drupal. If your editorial process needs three-stage approval, audit trail, scheduled publication and content lifecycle workflow, the headless-CMS-of-the-month is usually a step backwards.

Long-lived projects where the integration surface is a future liability. MACH means six vendors instead of one. Each vendor's pricing in year 5 is a separate negotiation. Each vendor's API breaking change is a separate incident. We've seen MACH ecommerce stacks become unmaintainable inside three years.

The intranet case study

A few years ago we built an intranet platform on MACH-style architecture for a UK organisation. It worked. It also took twice as long to build and is three times harder to upgrade than the same project would have been on a single Plone instance.

The lessons: MACH made the integrations cleaner but didn't add capability the client used. The eventual feature set was "intranet that does what an intranet does" — for which Plone already does, monolithically, cheaper.

How we decide

Count the frontends you actually have, not the ones the slide deck has. Count the teams that need to move independently. Count the vendors you're willing to manage in year five. If those numbers are big, MACH. If they're small, pick a good monolith and move on.

Architecture is meant to serve the project, not impress your peers. "Boring" beats "fashionable" approximately 80% of the time in our experience.