Micro frontends apply the principles of microservices to the frontend. Instead of a single monolithic frontend application maintained by one large team, the interface is composed of independently developed, deployed, and maintained fragments owned by different teams. This architecture solves real problems at scale — but introduces complexity that is not justified for smaller applications. Here is when and how to use it.
When Micro Frontends Make Sense
Micro frontends are a solution to organisational scaling, not technical scaling. If you have a single frontend team of 5-10 developers, a well-structured monolithic application is almost certainly the better choice. Micro frontends become valuable when multiple teams need to work on the same application independently — when coordination costs between teams exceed the complexity costs of distributed architecture.
Typical indicators that you might benefit from micro frontends include: deployment bottlenecks where one team's changes block another's releases, different parts of the application evolving at different speeds, teams wanting to use different technology stacks for different features, and the frontend codebase growing so large that build times and developer experience suffer.
Composition Patterns
- Module Federation: Webpack's Module Federation allows separately built applications to share code at runtime. One application can dynamically load components from another without rebuilding. This is the most popular approach for React-based micro frontends.
- Server-side composition: An edge or server-side layer assembles fragments from different micro frontends into a complete page before sending it to the browser. This approach offers better performance and SEO but requires more infrastructure.
- Web Components: Each micro frontend exposes its interface as custom elements. Framework-agnostic by nature, Web Components can be composed on any page regardless of what framework each team uses internally.
- iframes: The simplest isolation model. Each micro frontend runs in its own iframe with full CSS and JavaScript isolation. Limited by cross-frame communication constraints but effective for embedding third-party tools.
Shared Concerns
The biggest challenge in micro frontend architecture is managing shared concerns: routing, authentication, design consistency, and shared state. A shell application typically owns the global layout, routing, and authentication. Micro frontends plug into this shell and manage their own internal routing and state.
A shared design system is essential for visual consistency. Without one, each team's fragment looks and behaves differently, creating a disjointed user experience. Publish your design system as a versioned package that all teams consume. This provides consistency while allowing teams to update at their own pace.
Performance Considerations
Micro frontends can introduce performance overhead through duplicate dependencies, additional network requests, and larger bundle sizes. Mitigate this by sharing common dependencies (React, design system) through the shell application rather than bundling them into each micro frontend. Use lazy loading to ensure only the code needed for the current view is loaded. Monitor total page weight rigorously — the distributed nature of micro frontends means no single team sees the full picture of what the user downloads.
For most of our clients at Born Digital, monolithic frontends remain the right choice. But for enterprise clients with multiple development teams and complex applications, micro frontends provide the autonomy and deployment independence that large organisations need to move fast without stepping on each other.