Micro Frontends vs Modular Monolith: How to Choose

Choose a modular monolith when teams can share one release train without material delay. Choose micro frontends when several durable teams own separate business domains and coordinated frontend deployments are already slowing delivery. Both designs can enforce module boundaries. Only one creates independently deployed browser applications, versioned runtime contracts, remote loading states, and a larger operational surface. The deciding metric is not repository size. Measure how long changes wait for another team, how often one domain blocks the full release, how much rollback scope crosses ownership boundaries, and how many changes touch several domains. If those numbers are low, runtime distribution is expensive theatre. If they are high and persistent, one deployable frontend has become an organizational bottleneck. A repository can contain millions of lines and still work well as one deployment when ownership and release decisions remain aligned.

Distribution is a response to measurable coordination cost.

A modular monolith is one deployable application with boundaries enforced inside the codebase. Each domain owns routes, state, API clients, tests, and internal components. Imports cross boundaries only through published interfaces. The build and release remain shared, which keeps integration testing, dependency resolution, server rendering, local development, and rollback comparatively simple.

Do not confuse a modular monolith with folders named components, hooks, and services. Those are technical layers, so one customer feature still cuts across all of them. Domain modules such as search, checkout, billing, and account create vertical ownership. Tooling can enforce import rules, but ownership is the real control: one team reviews and releases changes to one capability.

• One artifact, one dependency graph, and one production version.
• Domain imports are explicit and checked in CI.
• Shared rendering and application state stay local to one runtime.
• A release can still include changes from several teams.

Micro frontends divide the product into separately built and deployed applications that appear as one interface. A shell usually owns top-level navigation, identity, layout, error boundaries, and telemetry. Domain applications own routes or vertical slices. Composition can occur on the server, at build time, through browser routing, or at runtime with tools such as Webpack Module Federation.

AWS describes the pattern as independently developed and deployed child applications integrated by a parent application. That independence changes the operating model. Teams now publish versioned artifacts, declare compatibility, observe remote load failures, manage shared dependency policy, and roll back one domain without rebuilding the rest. The feature is autonomy. The cost is distribution.

First, count durable teams. Two teams temporarily touching one product do not justify a permanent runtime boundary. Second, measure release contention. “Deployments feel slow” is weak evidence; median wait time and blocked releases per month are useful. Third, inspect domain stability. A boundary that moves every sprint will turn ordinary refactoring into cross-application migration.

Fourth, test end-to-end ownership. A team that owns a React remote but depends on another group for every API change cannot release independently. Fifth, price the platform work: artifact hosting, manifests, compatibility checks, local composition, source maps, observability, fallbacks, security policy, and on-call responsibility. If nobody owns that platform, every product team will build a different version of it.

• Are at least three stable teams shipping distinct business domains?
• Does frontend release coordination create measured delay?
• Can each team own its route through the API and data boundary?
• Can the organization operate and observe several web artifacts?
• Will the proposed domains remain useful for several years?

A modular monolith can deduplicate dependencies at build time and optimize one route graph. Micro frontends can ship duplicate framework, utility, and design-system code unless sharing rules are controlled. Runtime composition also creates network requests and failure states that do not exist when every module ships in one artifact. Measure JavaScript bytes and remote-entry latency by route, not only the shell bundle.

Distribution can reduce blast radius only when failure is isolated. A remote that throws during shell startup can still break the whole page. Each domain needs a loading state, timeout, error boundary, and fallback. Critical flows need a deliberate policy: checkout might fail closed with a clear recovery path, while an optional recommendation panel can disappear without blocking the page.

Start by creating domain ownership inside the monolith. Move routes, tests, API access, and state behind explicit boundaries. Track cross-domain imports and remove them. This work is necessary whichever architecture wins, and it tells you whether the organization can respect boundaries before deployment becomes distributed.

Extract one domain with high release contention and few synchronous dependencies. Route-level extraction is easier to reason about than splitting individual widgets across teams. Keep the old path available during rollout, compare errors and performance, and prove independent rollback. A migration that begins by federating the design system has chosen the most shared code as its first experiment. That is backwards.

• Define domain owners and public interfaces in the existing application.
• Measure coordination delay before changing deployment topology.
• Extract one route-level domain behind a reversible release control.
• Add remote-specific errors, web vitals, release markers, and rollback.
• Expand only after the first domain releases independently in practice.

A runtime-loaded remote is executable code entering the product shell. Treat its origin, manifest, release identity, and allowed capabilities as a security boundary. The shell should load remotes only from approved locations, apply a Content Security Policy suited to the deployment model, and expose narrow capabilities instead of handing every application unrestricted browser storage or a mutable authentication object.

Contracts need owners and support windows. A shell capability can publish a version, compatibility tests, and a removal date. Remote teams should prove compatibility before promotion, not after a customer loads the page. Source maps and release identifiers must resolve an error to one artifact and one owner. Without that, independent deployment turns incidents into a meeting where every team says its own build passed.

• Allowlist remote origins and control manifest promotion.
• Version shell capabilities and test them against supported remotes.
• Keep authentication and authorization decisions behind controlled interfaces.
• Attach errors and web vitals to exact shell and remote releases.

Set success criteria before extraction: release wait time, deployment frequency, rollback scope, route performance, error rate, and engineering time spent on the platform. If autonomy does not improve while runtime cost rises, stop. A technically successful extraction can still be a poor organizational investment.

Reversing is not failure. Domains can return to one deployment while keeping the ownership and module boundaries learned during migration. The valuable asset is a system whose boundaries match accountability. Whether those modules arrive in one bundle or five is a delivery choice that can change as the organization changes.

At PropertyGuru, I led a monolith-to-micro-frontend migration for four product teams. The useful decision was not choosing Module Federation. It was splitting ownership by business domain—listings, payments, analytics, and agent tools—so a team could change a customer capability without coordinating every frontend release.

We kept the shared foundation small: design tokens, authentication, navigation, and strict service contracts. A unified payment capability sat behind a stable interface consumed by all four teams. The release cycle moved from weeks to days because the deployment boundary matched accountability. If that relationship had not changed, several bundles would only have produced a more complicated monolith.