The argument in brief· 3–5 min read· full paper 29 pp

A Monolith Wearing a Transformer

What we un-learned about decoupling.

A domain foundation model is a strong supporting system and a poor primary one. Not because the model is bad. Because of what you can reason about at three in the morning when it is quietly wrong across four decisions at once.

01A number that came from nowhere

A research document proposed that routing, fraud, risk and checkout all be served from a single payments foundation model. It specified the model’s inference budget at 29 milliseconds, four times over, each instance carrying a citation marker.

The number appears in none of the vendor’s own materials — not the product page, the engineering blog, the launch release, or the chief executive’s newspaper interview. Nobody lied. A model produced a document about a real system, and a plausible latency landed in a slot that wanted one.

The failure is not fabrication as an act. It is fabrication as a shape: a document that looks cited, reads as technical, and carries one load-bearing quantity that came from nowhere.

That matters here because the same document, on the strength of numbers assembled that way, recommended re-coupling a system the industry spent two decades learning to decouple — in the one place where failure is most expensive.

02What service boundaries were actually for

Not development velocity. That was the conference pitch, and for many teams it never arrived. The durable benefit was containment, and the pattern has a name and a definition:

“for isolating parts of an application into pools or compartments so that failure of one component will not cascade to other components” The bulkhead pattern

A bulkhead does not prevent failure. It bounds it. A shared backbone serving all four decisions removes that compartment, which makes its failure a single point of failure by construction rather than by misconfiguration — and that distinction is the whole argument. A bug gets fixed and the architecture is unchanged. A design working as intended has no configuration that restores the boundary.

Redundancy does not rescue it, because the failure mode that matters is not the model being down. It is the model being wrong. Five replicas of a drifted model produce the same drifted answer five times, quickly.

This is not speculation. Somebody tried it, and published what happened:

“compromise the engineering requirements (latency, uptime) of online deployments in a critical flow.” Adyen, on combining decisions into bigger models

What failed was not accuracy. It was latency and uptime, in the synchronous path. And the same source says they are “expecting to move the whole pipeline to deep learning architectures in the short future” — both halves belong in the record, and the paper keeps both.