Microfrontend Boundaries: How to Decide Where to Split

Most teams adopt microfrontends with a specific pain in mind. Releases are slow. Builds take forever. One team blocks another. Microfrontends look like the fix.

Then they immediately ask the wrong question: "How do we split this?"

The instinct is to look at the codebase. Maybe split by tech stack (the React part here, the Angular part there). Or by folder structure (everything under /admin becomes its own surface). Or by ownership lines on a Confluence page (Team A's stuff goes here, Team B's stuff goes there).

All of these are technical splits. None of them necessarily align with how a user actually moves through the product. And that's the problem.

A microfrontend split along technical lines doesn't solve the problem you adopted microfrontends to solve. You still need three teams to coordinate to ship one feature. You still have a deploy cadence locked to the slowest surface. You just have more network calls and a more complicated build pipeline.

The better question is not "how do we split this?" It is "what's the smallest team that can own a workflow end to end?"

Workflows are the unit users care about. Sending an invoice. Onboarding a new customer. Reconciling payments. Each of these is something a user starts and finishes. Each is something a single team can own from API contract through to UI polish.

If you can identify the workflows clearly, the boundaries draw themselves. Each workflow becomes a candidate microfrontend. You stop arguing about whether the "Settings" page is its own surface (it isn't), because Settings isn't a workflow. Updating notification preferences is. So is changing billing details. The question is whether they're the same workflow owned by the same team, or different workflows owned by different teams.

When I'm looking at a workflow and trying to decide if it earns its own microfrontend, I run it through four tests.

Ownership test. Can one team own this workflow without coordinating across other teams on every change? If you have to pull in three other teams to ship a change to invoicing, invoicing is not really owned by one team. Don't make it a microfrontend until ownership is clear. A microfrontend with shared ownership is the worst of both worlds: you get the build complexity without the coordination win.

Release rhythm test. Does this workflow ship on its own cadence, or is it always coupled to something else? If it always ships with the rest of the app, the microfrontend isn't buying you anything. If it has its own release pressure (a critical fix needs to go out, but everything else is mid-merge), that's a real signal it should be independently deployable.

Failure isolation test. If this workflow breaks in production, what does the user lose? If a bug brings down the whole app, you have hidden coupling that microfrontends won't fix on their own. If only this workflow is affected, you have real isolation, and microfrontends amplify that benefit.

Team-size test. Is this surface big enough that two or more engineers can sustainably own it for the next year? Microfrontends carry a maintenance tax: build configs, dependency upgrades, shared libraries, cross-surface routing. If a workflow is small enough that one engineer touches it twice a year, splitting it out makes the system more complicated without any of the upside.

If a workflow passes all four tests, it's a strong candidate. If it passes three, sometimes still worth it but with eyes open. If it fails two or more, the boundary isn't there yet. Leave it inside the monolith and revisit later.

The first time I sketched these boundaries for the AR platform, I went too granular.

Each invoice action looked like a workflow to me. Send invoice, edit invoice, void invoice, mark as paid. So I drew lines around each. Five microfrontends just for invoicing.

It looked clean on paper. In practice, it would have been awful.

The actions shared too much state. The same invoice list, the same filters, the same selection model. Splitting them would have meant either duplicating that state in every surface or building a shared state layer that every surface had to import, which defeats the point of independent deploys.

We pulled back. Invoicing became one surface that owned the full invoice lifecycle. Payments became another. Customer management became a third. Three microfrontends, not fifteen.

The lesson: workflows are bigger than they look. A workflow is "I want to manage invoices," not "I want to click the void button." Granularity that looks elegant at the design stage often hides shared state that makes the granular split worse than the monolith.

When in doubt, draw the boundary one level coarser than your first instinct.

Microfrontend boundaries are a leadership decision dressed up as a technical one.

The technical machinery is the easy part. Module Federation has docs. Single-spa has examples. You can wire up build-time stitching, runtime stitching, or federated modules in an afternoon if you know what you're doing.

What's hard is knowing which lines to draw. That takes business context, customer context, team context, and the willingness to revisit a boundary you got wrong without making it political.

The teams that get microfrontends right are not the ones with the best Module Federation config. They're the ones who treated the boundary decision as a real product question, talked to the people who owned the workflows, and were honest when the first split didn't work.

If you're picking up microfrontends right now, start with the workflows. The infrastructure will sort itself out.