One of the most recurring situations I’ve seen across companies is the decision between monorepo and micro-frontends. What used to be a technical discussion has become an industry-wide dilemma — often driven by trends rather than context.
In one case, two frontend applications were serving the same business domain. They shared features, logic, and a converging roadmap, yet lived in separate repositories and were owned by different teams. As both systems scaled, the problem was no longer delivery — it was coordination, consistency, and long-term maintainability.
Micro-frontends looked like the obvious answer. They promised autonomy and independent deployments. But when evaluated against the business direction, expected convergence, and team structure, they solved the wrong problem.
The real challenge wasn’t independence. It was shared evolution.
A carefully structured monorepo, with clear domain boundaries and ownership, aligned better with the future of the product. It reduced duplication, simplified collaboration, and preserved developer velocity — without introducing orchestration complexity that wasn’t needed.
This insight exists to make that point clear: architecture choices should follow business reality, not industry fashion.
The Era of Orchestration
Modern frontends require coordination across squads and clear boundaries as applications grow. In today’s complex applications, scaling isn’t just about writing more code—it’s about enabling team autonomy.
As a tech lead, I’ve seen monolithic repos grow so large that even a small change could trigger a 20+ minute build, grinding developer velocity to a halt. This “Era of Orchestration” shifts the focus from individual components to the entire system: defining clear service boundaries, automating pipelines, and giving each team the freedom to ship features independently.
This tension between team autonomy and shared evolution is a defining characteristic of the Era of Orchestration.
"Modern dev environments require tools that break giant frontends into manageable pieces."
Module Federation vs. Monorepos
When an app grows beyond what one team can own, we face a choice: split it into micro-frontends (often using Webpack’s Module Federation) or keep it in a monorepo (with tools like Turborepo or Nx).
Monorepos excel at developer experience: shared code and types are easy to reference, consistent linting/tests keep quality high, and global refactorings are straightforward. However, a full-repo build still scales poorly.
Module Federation, by contrast, lets you expose and consume UI components at runtime, so each team can deploy its slice independently without rebuilding the whole app. This has become crucial in enterprises: teams can own vertical slices of functionality (e.g. billing, reporting, dashboard) and ship on their own cadence. But it comes with trade-offs: you must carefully manage shared dependencies and cross-app state.
"The best architecture is the one that allows your team to move fast without breaking things for others."
When Micro-frontends Are the Wrong Choice?
Micro-frontends are not a default upgrade path. In many cases, they introduce more overhead than value.
You should be cautious about adopting micro-frontends when:
- Teams are working on the same business domain with significant overlap.
- Features are expected to converge rather than diverge over time.
- There is heavy shared state or shared business logic.
- The organization lacks strong platform, DevOps, or observability maturity.
- Independent deployment is a nice-to-have rather than a hard requirement.
In these scenarios, micro-frontends often shift complexity rather than reduce it — replacing coordination in code with coordination in runtime, pipelines, and operations.
Monorepo vs. Micro-frontends: A Practical Lens
- Choose a Monorepo when: Teams share a large amount of business logic, features evolve together, consistency matters, and you want strong guardrails with minimal runtime orchestration.
- Choose Micro-frontends when: Teams own clearly separated business domains, independent deployments are critical, release cadences differ significantly, and organizational scale demands strict autonomy.
Key Strategies for Success
- Domain-driven splits: Organize your apps by business domain (checkout, profile, etc.) rather than technical layers.
- Shared design system: A centralized, versioned UI library is non-negotiable.
- State & communication: Minimize cross-app global state.
- Performance budgets: Set measurable goals (FCP, LCP, TTI, etc.) per micro-frontend.
- Observability & Monitoring: Treat each frontend fragment as a service.
- CI/CD Pipelines: Automate everything.
- Automated Testing: Enforce unit and end-to-end tests across remotes.
- Modern Tooling: Embrace up-to-date technologies.
To visualize this orchestration, consider the following configuration. This is an example showing how Module Federation bridges the gap between build-time boundaries and runtime integration, allowing independent squads to 'expose' their features to a host shell.
new ModuleFederationPlugin({
// The name of the remote application. Must be unique across the ecosystem.
name: 'app_dashboard',
// The name of the remote entry file. This is what the host will download.
filename: 'remoteEntry.js',
// Maps which internal components are shared with other applications.
exposes: {
'./DashboardStats': './src/components/DashboardStats',
},
// Libraries shared between the host and remotes to prevent duplicate downloads.
shared: {
// Singleton ensures only ONE instance of React exists in the entire runtime.
react: {
singleton: true,
eager: true, // Loads immediately; useful for critical library components.
requiredVersion: false // Can specify semver ranges (e.g., '^18.0.0')
},
'react-dom': {
singleton: true,
eager: true
},
},
});Conclusion
Building a frontend for scale requires thinking beyond components and frameworks. It requires designing systems that reflect how teams collaborate, how products evolve, and how businesses grow.
Whether you choose a monorepo or micro-frontends, the measure of success is the same: does this architecture allow teams to move fast without creating friction for others?
Trends will change. Tools will evolve. What endures is the need for clear boundaries, deliberate trade-offs, and decisions grounded in reality rather than fashion.
Make architecture choices that serve your future — not just the moment.