At Broadleaf, we are committed to MACH principles and have been for over a decade. Originally, we supported API first and headless aspects of MACH but since 2019, our focus has been on our Microservices (fully MACH) offering.

The opinion that MACH is important to enterprise commerce is not a position unique to Broadleaf and many of our competitors also describe their solutions using MACH terminology. For SaaS based solutions, the same four letters can mean something different and that difference is important to our customers.

Three letters we agree on

Microservices let teams deploy and scale parts of the system independently, and the bounded contexts the architecture enforces are a real improvement over the bloat of a legacy monolith.

API-first decouples front end from back end through a contract, so multiple customer-facing applications can share the same functionality and back-end implementations can change without disrupting the experiences built on top of them.

Headless separates storefront from commerce logic so each can evolve on its own schedule.

These three principles are important and generally agreed to by commerce vendors serving the space.

The fourth letter has a delivery model hidden inside it

The C is often shorthanded as cloud-native. Historically, many vendors in the space, including the standards bodies, have spelled that out as cloud-native SaaS: software that leverages the cloud beyond storage and hosting, including elastic scaling and automatic updates. That framing has faded in more recent industry conversation, and for good reason: three of the four MACH principles describe how software is built. The SaaS half of that older definition was always describing who operates it, and that's an ownership question, not an architecture one.

Elastic scaling and automatic updates are genuine engineering properties, and we deliver both. Vendor-operated multi-tenancy is not an engineering property. It is a business model. Folding it into an architecture standard is the one place where the industry quietly makes a commercial decision on your behalf.

SaaS MACH: the C serves the operator

In the SaaS model the platform is operated by the vendor, typically as a multi-tenant service. There is real value in that, and for many businesses it is the right answer.

In fact, if you are buying SaaS, does it matter to you whether the vendor is MACH internally, or only that they deliver the APIs and reliability guarantees you need? I would side with those vendors here: building on MACH principles is a large part of how they keep those API and reliability promises.

But operation is control, and in a multi-tenant platform the control sits with the vendor. Your code cannot run inside their process. That shows up the moment you need to extend core logic, where your options narrow to the extension points someone else imagined for you: routing, latency-bound orchestration, and hooks.

Shared infrastructure also has to be protected from the tenants sharing it. That protection surfaces commercially, as API volume pricing and rate limiting, either metered directly or folded into GMV-based pricing. At best, your bill grows in proportion to your success.

None of this is a vendor behaving badly. It is the rational shape of one operator serving many tenants. Delivered as SaaS, the C is optimized for the operator. That is not a flaw in those products. It is who they were built to serve.

The agentic shopper is about to test that pricing model

Every one of those metered models was calibrated against human traffic, and human traffic has a natural governor on it. A person takes a few seconds between clicks, reads a page, thinks, and clicks again.

An agent does not. An AI shopping assistant assembling and summarizing options on a buyer's behalf can burn ten times the API calls a human would, or more, to produce a single decision. The same is true on the back end, where AI-assisted merchandising and support tooling will drive call volumes that no one modeled when these contracts were written.

So the question worth asking any vendor priced on API volume or GMV is a simple one: what happens to my bill and my rate limits when half my traffic is agentic? Nobody has a confident answer yet. That is precisely why it is worth asking before you sign, not after.

Where you own the runtime, the question does not arise. Agent traffic is compute you provision, not a line item someone else meters.

Broadleaf MACH: the C serves you

Keep all four principles and change three things.

First, extend core microservices with your own business domain and rules, in code, not through predefined hooks. Second, run it in your own cloud account. Third, integrate directly with the microservices your own teams have built, in the same cloud regions.

None of that sacrifices cloud-native engineering. Broadleaf deployments use managed database engines such as Cloud SQL, AlloyDB, or Amazon Aurora. Our default messaging infrastructure is a cloud-neutral Kafka configuration, but because we build on Spring Cloud Stream, we also support provider-native messaging such as Google Pub/Sub or Amazon Kinesis. These are the same managed cloud services a SaaS vendor leans on. The difference is that they are the ones you chose, running next to the systems you already operate, rather than the ones we chose for you.

It is also worth noting that Broadleaf Microservices can run in your own data center for clients who want to protect that investment, with the added benefit of using patterns that port cleanly to the cloud if that decision changes later.

The consequences are concrete. The process boundary is yours, so custom pricing logic runs in-process and the round trip disappears. There is no artificial throttle, so a batch job runs at the speed of your own database. Cost scales with the compute and storage you provision on AWS or GCP, not with your revenue. And the roadmap is yours: when you need a capability, you build it and ship it instead of waiting for it.

I will not pretend ownership is free. When you own the platform, you carry operational responsibility a SaaS vendor would have carried for you. We partner closely with clients on exactly that, because custom commerce is built, not rented off a shelf. If commerce is not where you differentiate, renting the C may well be the better move.

Our C also stands for Customer, and for Control

The letter stands for cloud-native. In our MACH, the C also stands for Customer and for Control: cloud-native infrastructure that you own, run, and extend. That is the frame the entire company is built on, and it is why the C answers to you rather than to us.

Now reverse the earlier condition. If commerce is the business, if your volume and complexity are the thing you compete on, then control over the platform is not an implementation detail. It is the competitive position itself. Renting it taxes the exact part of the business that is supposed to be your advantage.

That is the company we build for.