Micro-frontend architecture extends the microservices principle to the frontend — breaking a large web application into smaller, independently developed, tested, and deployed frontend modules that compose together into a unified user experience. This approach allows multiple teams to work on different parts of a web application simultaneously without stepping on each other’s code, using different technology stacks if needed.
Why Would You Choose Micro-Frontends Over a Monolithic Frontend?
The monolithic frontend — a single codebase for the entire user interface — works well for small to medium applications. Micro-frontends become valuable when:
- Multiple teams own different features — A product team, a checkout team, and a content team each need to ship independently without coordinating deployments.
- The codebase has grown unwieldy — Build times are long, testing is slow, and changes in one area unexpectedly break another.
- Technology migration is needed — You want to incrementally migrate from an older framework (e.g., Angular.js) to a newer one (e.g., React or Vue) without a risky big-bang rewrite.
- Different parts have different scaling needs — A product catalog might need heavy caching and static generation, while a real-time dashboard needs a completely different architecture.
- Organisational autonomy matters — Teams want full ownership of their feature area, from development through deployment and monitoring.
What Are the Main Implementation Approaches?
| Approach | How It Works | Pros | Cons |
|---|---|---|---|
| Module Federation (Webpack 5) | Modules loaded at runtime from separate builds | Share dependencies, true runtime integration | Webpack-specific, version management complexity |
| Single-SPA | Framework-agnostic orchestrator mounts/unmounts apps | Mix frameworks, mature ecosystem | Routing complexity, shared state challenges |
| iFrames | Each micro-frontend in its own iframe | Complete isolation, simplest integration | Performance overhead, communication complexity, accessibility issues |
| Web Components | Custom elements encapsulate each micro-frontend | Framework-agnostic, native browser support | Shadow DOM limitations, SSR challenges |
| Build-time composition | Packages published to npm, composed at build time | Simple deployment, familiar tooling | Not truly independent deployment |
What Are the Key Design Decisions?
- Vertical vs horizontal split — Vertical splitting assigns each team a full page or feature area (e.g., product pages, checkout, account). Horizontal splitting places multiple micro-frontends on the same page (e.g., header, product list, recommendations). Vertical is simpler; horizontal requires more coordination.
- Shared design system — A common component library and design system ensures visual consistency across micro-frontends. This is non-negotiable for a good user experience.
- Shared state management — Define how micro-frontends communicate: custom events, a shared state store, URL parameters, or a pub/sub message bus. Keep shared state minimal.
- Routing strategy — Decide whether a shell application handles routing and delegates to micro-frontends, or each micro-frontend manages its own routes.
- Deployment infrastructure — Each micro-frontend needs its own CI/CD pipeline, hosting, and CDN configuration for truly independent deployment.
What Are the Trade-offs You Should Understand?
Benefits:
- Independent team autonomy and faster shipping cycles
- Incremental technology migration without full rewrites
- Isolated failures — a bug in one micro-frontend does not crash the entire application
- Smaller, faster builds and more focused testing
Costs:
- Increased infrastructure complexity — more pipelines, more deployments, more monitoring
- Potential for inconsistent user experience without a strong shared design system
- Performance overhead from loading multiple frameworks or duplicate dependencies
- Cross-micro-frontend communication adds architectural complexity
- Debugging becomes harder when issues span multiple micro-frontends
When Should You Not Use Micro-Frontends?
Micro-frontends are not the right solution for every project. Avoid them when:
- A single team builds and maintains the entire frontend
- The application is small enough that a monolith is manageable
- Your team lacks the infrastructure expertise to manage multiple deployment pipelines
- The user experience requires extremely tight integration between features
For Indian development agencies serving clients of varying sizes, the practical advice is clear: recommend micro-frontends only for projects with genuine scale challenges and multiple teams. For most mid-market projects, a well-structured monolithic frontend with clear module boundaries is simpler, faster, and more cost-effective.
Frequently Asked Questions
Do micro-frontends hurt page load performance?
They can, if implemented poorly. Loading multiple JavaScript bundles, potentially with duplicate dependencies, increases initial page weight. Mitigations include shared dependency management through Module Federation, aggressive code splitting, lazy loading non-critical micro-frontends, and a CDN with proper caching headers.
Can different micro-frontends use different frameworks?
Technically yes — this is one of the advertised benefits. Practically, using multiple frameworks (React in one, Vue in another, Angular in a third) significantly increases bundle size and maintenance burden. Most successful implementations use the same framework across micro-frontends and reserve framework mixing for incremental migration scenarios.
How do you maintain a consistent look and feel across micro-frontends?
A shared design system is essential. This typically takes the form of a published component library (npm package) containing buttons, forms, typography, layout components, and design tokens (colours, spacing, fonts). All micro-frontend teams consume this library, ensuring visual consistency without tight code coupling.
What is the minimum team size where micro-frontends make sense?
As a general guideline, micro-frontends begin to provide value when you have three or more frontend teams working on the same application, each responsible for a distinct feature area. Below that threshold, the coordination overhead of a shared monolithic codebase is usually lower than the infrastructure overhead of micro-frontends.
