MACH-Aligned Without Being MACH-Certified: What Composable Actually Costs
"Must be MACH-certified" shows up in retail RFPs as though it were a technical requirement. It is not one. It is a vendor membership programme, and confusing the two leads teams to buy an architecture they have not costed.
The gap matters because composable commerce is a real improvement for the right retailer and an expensive mistake for the wrong one. The difference is rarely the technology. It is whether the team has budgeted for the seams.
What certification actually certifies
The MACH Alliance runs a member certification, which it describes as independent verification assessed against a published standard, backed by production deployments and reference customers. That is a meaningful signal about a vendor. It says nothing about whether your architecture is any good.
Worth noting how the Alliance's own framing has moved. The current explanation leads with 3 principles, open, composable, and connected, rather than a strict reading of the original acronym. Openness is described in terms of actions being visible, auditable, and trustworthy, which is an operational property rather than a procurement one.
So a retailer can run a certified vendor inside a badly composed system, and can run an excellent composable system on components whose vendors have never applied. The certification is a supplier filter. Your architecture is your problem.
The useful reframe is to ask what composable buys you. It buys independent replaceability: the ability to swap one capability without a programme. Everything below is what that costs.
Seam 1: concurrency stops being the database's problem
In a suite, 2 concurrent edits to the same product hit one transactional boundary and the database sorts it out. In a composable system the record lives behind an HTTP API and the database guarantee is gone.
What replaces it is optimistic concurrency, and every vendor implements it slightly differently. RFC 9110 defines the HTTP-native form: the server issues an ETag validator, the client sends it back in an If-Match header, and a mismatch returns 412 Precondition Failed instead of silently overwriting the other writer's change.
Plenty of commerce APIs do it differently. commercetools documents an explicit version field carried in the request body, returning a ConcurrentModification error on mismatch, and states plainly that it does not use ETag and If-Match headers for this.
Neither approach is wrong. The cost is that your integration layer now handles 2 or 3 different conflict conventions, and every write path needs a documented answer to what happens on conflict.
Concretely, budget for these on each write path:
- A read-modify-write loop with a bounded retry count, not an unbounded one.
- A defined resolution rule per field, because "retry the whole payload" reintroduces the lost update you were preventing.
- A conflict metric per entity, since a rising conflict rate is the earliest signal that 2 systems both think they own a field.
- A deliberate answer for bulk operations, where a 500-item import hitting 3 conflicts should not fail all 500.
Seam 2: eventual consistency reaches the customer
Composable systems replicate. A price change written to the pricing service reaches search, the storefront cache, and the promotion engine at different moments, and during that gap the site is internally inconsistent.
Werner Vogels named the property precisely in Eventually Consistent. The inconsistency window is the period between an update and the moment every observer is guaranteed to see it, and its width depends on replica count, load, and communication delay.
The model that matters most in commerce is read-your-writes: after a customer changes something, that customer must see the change. Vogels describes it as a special case of causal consistency, and notes it usually requires either client stickiness or the client tracking version numbers itself.
In practice that produces a small number of rules worth writing into the design:
- Any surface a customer just wrote to reads from the source of truth, not from a replica or a CDN cache.
- Price and stock are validated once more at checkout, whatever the catalogue said 90 seconds ago.
- Inconsistency windows get a target and a monitor, because an unmeasured window widens until someone complains.
- Merchandisers get told the real propagation time, since the alternative is a support ticket every time an edit takes 40 seconds to appear.
None of this is exotic. It is simply work that a monolithic suite did not ask you to do.
Seam 3: the operational surface you inherit
A suite gives you 1 vendor to call, 1 status page, and 1 log to read. A composable stack gives you 6 vendors, 6 status pages, and an incident where the only honest first statement is that checkout is slow and nobody knows which hop.
Distributed tracing stops being a nice-to-have at that point. OpenTelemetry describes context propagation as the core concept that makes distributed tracing work, correlating spans into a single trace regardless of which process, service, or data centre produced them.
The practical requirement is unglamorous. Every call between components carries trace context, every vendor boundary is a span with the vendor named as an attribute, and a single order identifier is queryable across every service that touched it.
This is the line item most composable business cases omit. Tracing infrastructure, correlation identifiers, an on-call rotation that spans vendor boundaries, and a runbook per integration are a permanent operating cost, not a project cost.
Seam 4: vendor release cadence becomes your release cadence
SaaS components ship on their own schedule. Deprecations arrive with the vendor's notice period rather than yours, and 6 vendors mean 6 independent deprecation calendars pointed at your integration layer.
The mitigation is an adapter per vendor, so a breaking change is contained in 1 module instead of scattered through domain code. It also means contract tests running against vendor sandboxes on a schedule, so you find the breaking change before your customers do.
Budget engineering capacity for this permanently. A composable estate with no standing allocation for vendor upgrade work accumulates version debt until an upgrade becomes a project.
Seam 5: identity and the copies of the customer record
Composable stacks replicate customer data by design. The CDP holds a profile, the commerce engine holds an account, the loyalty component holds a member record, and the support tool holds a contact.
Each copy exists for a good reason and each one is a separate answer to the question of who the customer is. Reconciling them is ongoing work rather than a migration task.
Two operations expose the cost immediately. A deletion request has to fan out to every component that holds a copy, with proof it completed, and a merge of 2 duplicate customers has to propagate without leaving one component pointing at a record the others retired.
Authorization is the other half. Each component has its own permission model, and a role that means one thing in the commerce engine means something looser in the CMS. The integration layer becomes the only place where a coherent answer can live.
Design for it explicitly. One component owns the canonical customer identifier, every other copy stores that identifier as a foreign key rather than minting its own, and deletion and merge run as tracked workflows with per-component acknowledgement.
The alternative is discovering during a privacy request that a component holds an email address nobody remembered writing to it.
Suite versus composable, honestly
| Dimension | Integrated suite | Composable |
|---|---|---|
| Concurrency | Database transactions, mostly invisible to you | Optimistic concurrency per API, conflict handling you write |
| Consistency | Strong within the suite boundary | Eventual across components, with a window you must measure |
| Change to 1 capability | Regression-test the suite, wait for the vendor release train | Deploy 1 service, subject to contract tests |
| Incident triage | 1 vendor, 1 support contract | Multiple vendors, tracing required to place blame accurately |
| Team shape | Suite specialists | Integration and platform engineers, plus a standing upgrade allocation |
| Failure mode | Locked into a roadmap you do not control | A distributed system built by a team sized for a monolith |
| Best fit | Standard commerce needs, small platform team | A genuine differentiator in 1 or 2 capabilities, with the team to run it |
What "MACH-aligned" should mean in your contract
Since certification is a vendor property, the alignment claim needs teeth of its own. Write it as testable properties rather than an adjective.
- Every capability is replaceable behind an adapter, demonstrated by an actual swap of at least 1 component during the build.
- Every write path documents its concurrency mechanism and its conflict resolution rule.
- Every asynchronous propagation has a stated target window and a monitor on it.
- Every cross-component call propagates trace context, verified by an end-to-end trace on a real order.
- Every vendor integration has contract tests running against a sandbox on a schedule.
Those 5 lines are worth more in a statement of work than any certification clause. They are also the 5 things that get quietly dropped when a composable programme runs late.
When the suite is the right answer
If your commerce requirements are close to standard, your platform team is small, and no single capability is a competitive differentiator, a suite will beat a composable build on total cost and on time to change. That is not a compromise, it is a correct reading of the constraints.
Composable earns its cost where 1 or 2 capabilities genuinely differentiate the business, and where those capabilities need to change faster than a suite release train allows. Search, pricing, and fulfilment orchestration are the usual candidates.
The best-performing retail architectures we see are rarely pure anything. A stable suite core with 2 or 3 capabilities pulled out and run independently is a common shape, and it is not less serious for being a hybrid.
FAQ
Is MACH certification worth anything at all in vendor selection?
Yes, as one input. It indicates the vendor has been assessed against a published standard with reference customers behind it, which is more than a marketing page provides. It is not evidence about your architecture and should not be scored as though it were.
How wide should an inconsistency window be before it is a problem?
Set the target from the customer-visible consequence rather than a general number. A merchandising edit tolerating 30 seconds is fine; an inventory decrement that a customer can race is not, which is why stock is revalidated at checkout regardless of what the catalogue reported.
Can we adopt composable one capability at a time?
That is the only version that reliably works. Extract the capability with the clearest business case, run it behind an adapter, and pay the tracing and contract-testing costs on that 1 component before adding a second.
Do we need a separate platform team to run a composable stack?
You need the function, though not always a separate team. Someone has to own the adapters, the contract tests, the trace pipeline, and the vendor upgrade calendar. Where that ownership is left implicit, it defaults to whoever is on call during the next incident.