Micro Frontends vs Modular Monolith

Should we split this into micro frontends?

Do we need runtime independence, or do we only need better internal structure?

frontend-app
├── home
├── catalog
├── product-details
├── cart
├── checkout
├── orders
├── profile
└── shared

One repository
One build pipeline
One deployment
One runtime
One dependency graph
One release cycle

The team is small.
The product is still evolving quickly.
The release cycle is shared.
The codebase is manageable.
The app has limited domains.
The CI/CD pipeline is not a bottleneck.
Independent deployment is not required.

Startup MVP
Internal dashboard
Small SaaS app
Single-team product
Marketing site
Simple admin portal

src/
├── app/
├── features/
│   ├── catalog/
│   ├── cart/
│   ├── checkout/
│   ├── orders/
│   └── profile/
├── shared/
│   ├── ui/
│   ├── hooks/
│   ├── utils/
│   └── config/
└── platform/
    ├── auth/
    ├── routing/
    └── analytics/

One deployment
But clear internal boundaries

Feature-based folders
Clear domain ownership
Restricted imports
Shared design system
Consistent routing
Centralized build
Single deployment pipeline
Strong internal boundaries

checkout should not import internal files from catalog
cart should not mutate checkout state
features should use shared contracts, not private internals

Shell App
├── Catalog Remote
├── Cart Remote
├── Checkout Remote
├── Orders Remote
└── Profile Remote

Own repository
Own build pipeline
Own deployment
Own team
Own runtime artifact
Own monitoring
Own rollback path

Independent team ownership
Independent deployment
Domain-level release autonomy
Runtime composition
Incremental migration
Per-domain scaling
Technology migration flexibility

Runtime loading failures
Dependency sharing complexity
Routing coordination
Testing complexity
Version compatibility issues
Deployment governance
Observability requirements
Rollback complexity

Catalog
Cart
Checkout
Orders
Profile
Search

Button
Header text
Product image
Price label
Small filter component

If the domain can be owned, tested, deployed, monitored, and rolled back independently, it may be a good micro frontend boundary.

Simple
Predictable
Easy rollback
No runtime composition risk

All teams share release cycle
One broken area can block deployment
Large builds can become slow

Independent releases
Per-team ownership
Smaller deployment blast radius
Faster domain-level delivery

Version mismatch
Runtime loading failure
Shared dependency conflict
Rollback coordination
Manifest governance needed

Unit tests
Component tests
Integration tests
E2E tests

Unit tests per remote
Contract tests
Shell integration tests
Remote loading tests
E2E cross-remote tests
Visual regression tests
Deployment smoke tests
Production monitoring

Large JavaScript bundle
Too much shared code
Poor code splitting
Slow builds

Duplicate dependencies
Remote loading waterfall
Multiple runtime chunks
remoteEntry.js loading cost
Inconsistent caching
Layout shift from late-loaded remotes

Route-level lazy loading
Bundle budgets
Shared dependency governance
Preloading critical remotes
Web Vitals monitoring

Do we have multiple frontend teams?
Are domains clearly separated?
Do teams need independent deployments?
Is the shared release cycle slowing delivery?
Do we have CI/CD maturity?
Do we have a shared design system?
Can we manage dependency versions?
Can we monitor remote failures?
Can we roll back one domain independently?
Is the added complexity justified?

The team is small.
The app is early-stage.
The product changes rapidly.
Domain boundaries are unclear.
One deployment pipeline is acceptable.
CI/CD is not a bottleneck.
The team wants simplicity.
The app does not need independent frontend releases.

src/
├── features/
│   ├── catalog/
│   ├── cart/
│   ├── checkout/
│   └── profile/
├── shared/
│   ├── ui/
│   ├── hooks/
│   └── utils/
└── app/
    ├── routes/
    ├── providers/
    └── layout/

Feature-based folders
Clear import rules
Shared design system
Domain-level ownership
Route-level code splitting
Testing boundaries
Type-safe contracts
Lint rules for module boundaries

features/checkout cannot import from features/cart/internal
features/checkout can call shared cart contract or API

Multiple teams own different domains.
Independent deployment is required.
The frontend monolith blocks delivery.
Domains are stable and well understood.
CI/CD maturity is high.
Design system maturity is high.
Teams can own monitoring and incidents.
Rollback per domain is needed.

Large e-commerce platform
├── Catalog Team
├── Cart Team
├── Checkout Team
├── Orders Team
├── Profile Team
└── Platform Team

There is only one frontend team.
The app has fewer than a few major domains.
No team needs independent deployment.
The shell and remotes are owned by the same people.
There is no design system.
There is no contract testing.
There is no rollback strategy.
The only motivation is “modern architecture.”

We should use micro frontends because big companies use them.

We have six frontend teams blocked by a shared release pipeline, with clear domain ownership and mature CI/CD.

Start with a modular monolith.
Enforce domain boundaries.
Add route-level code splitting.
Introduce shared design system.
Improve CI/CD.
Measure team bottlenecks.
Move to micro frontends only when needed.

Stage 1: Monolith
Stage 2: Modular monolith
Stage 3: Route-level code splitting
Stage 4: Extract one remote
Stage 5: Micro frontend platform

“Micro frontends are always better.”

“We should make every page a micro frontend.”

“Micro frontends are just multiple React apps.”

“We do not need a modular monolith if micro frontends exist.”

“Independent deployment is easy; just deploy each app separately.”

“The shell can own all shared business logic.”

Choose modular monolith.

Micro frontends may be justified.

Simplicity
Single deployment
Clear internal structure
Lower runtime complexity
Faster early development

Independent team ownership
Independent deployment
Domain-level release autonomy
Incremental migration
Large-team scalability