R5.3 · Specify how a micro-frontend is loaded, and make independent deployability the test

Theme	R5 · Technology stack
Domain	Portal and application architecture
Status	Proposed
Needs client validation	Yes
Reinforces	R3.1 — micro-frontends as a web rendering choice, given the contract that makes them one
Anchored in	The ADS's technology stack table and its two key design decisions, both pending LARB · the options deck's concerns 1 and 2
Open questions	Raises 34; depends on 18
Deliverables	D2.1 · D3.1

Concern

The composition pattern is named. The mechanism that makes it a pattern is not.

The stack table names a framework and a UI library and stops. Next.js for SSR and routing, React for the SPA UI, and three new components: the Dashboard Shell, the Integration API, and the per-BU MFEs. Nothing in the corpus says how an MFE reaches the shell — a versioned package resolved at build time, a remote loaded at runtime, or an iframe. Those are three different architectures wearing one word on the diagram.

Both decisions that would settle it are pending LARB while the build proceeds. The ADS records the frontend composition strategy (recommended Option C — hybrid shell plus MFE for web, thin native for mobile, shared Integration APIs) and the design system selection (recommended Option C — MUX as a Canada Segment library on the GDS core) as pending LARB approval, and the delivery team is building against them.

Why the mechanism is the decision

Because build-time packaging deletes the property the pattern exists to provide. If a business unit's tile ships as a dependency the shell compiles, then a Group Benefits change is a shell release, and a shell release is a six-line-of-business release. That is precisely the blast radius the options deck names first — "one bad BFF release breaks all six LOBs for all customers" — reproduced at the rendering tier, and it is the mechanism by which its second concern arrives: Conway's Law strangling velocity around line of business number four, with the shell team as the queue for six roadmaps.

The design system half is the same decision seen from the other side. Six MFEs each free to pin their own version of the shared library is six copies of the framework runtime on one page — measured against the ADS's own commitment that 99% of shell pages load under one second — and visual drift across a surface whose purpose is to look like one company.

Recommendation

Make the MFE integration contract an architectural decision with three parts, and make independent deployability its acceptance test.

Runtime loading, not build-time packaging. Module Federation, or Next.js multi-zone routing where a whole route belongs to one line of business. The test is one sentence and it is answerable on paper: can a business unit ship a change to its tile without a shell release? If the answer is no, the MFEs are libraries, and the delivery autonomy in the business case is not there.

One versioned design system contract. MUX on the GDS core, published as a semantically versioned package, with the shared framework runtime supplied by the shell as a singleton rather than bundled per remote. State the support window — how many minor versions behind the shell an MFE may run before it is refused. Without that number the singleton is an aspiration and every upgrade is a six-team negotiation.

A failure contract per MFE. A remote that fails to load, or loads and throws, must not take the page down. This is R2.1's degradation contract expressed at the rendering tier, and the browser is the one place it can actually be enforced — an error boundary per remote, with the tile rendering its own unavailable state.

Say what it costs. Runtime loading is more operational machinery than a package: a remote manifest, version negotiation, a rollback path per remote, and a shell that can be wrong about what it is loading. That is the price of the autonomy. It should be paid deliberately rather than discovered, and it is a reason the decision belongs in front of LARB rather than inside a sprint.

What it changes

It gives LARB something decidable. The frontend composition KDD recommends a hybrid and does not specify the integration mechanism, which is part of why it can sit pending while the build proceeds — there is nothing in it that a review either approves or refuses at the level where it matters.

It fixes the meaning of "micro-frontend" in D2.1. The portal architecture section cannot name a pattern whose definition changes by a factor of six teams depending on an unwritten choice.

It adds a platform owner to the roadmap. Somebody owns the shell contract, the remote manifest and the design system's release train. That is the same gap open question 14 records for the shared runtime, arriving from the front end.

What we are not recommending

Abandoning micro-frontends. R3.1 already places them: a web rendering choice, not the architecture's composition model. This page is what makes that placement hold.

Reopening MUX versus GDS. The KDD's recommendation is reasonable and this recommendation is agnostic to which library wins. What it asks for is a version contract, which is missing either way.

A bundler configuration. SOW Schedule "A" §3.0 puts implementation-level design out of scope. The recommendation is the contract and the test that proves it, not the configuration that implements it.

Dependencies and open questions

• Open question 34 — the MFE integration mechanism and the design system version contract, which this page raises and takes a position on.
• Open question 18 — the composition pattern for the target state. A later move to per-LOB BFFs or federated GraphQL changes what sits behind each remote; it does not change the loading contract in front of it, which is an argument for settling this one first.
• A LARB date for both key design decisions. Building against a pending recommendation is the condition that makes an unspecified mechanism permanent.