Mike's Notes
A good way to think of this. It's added clarity to Pipi UI's architecture, so I need to make a tiny change to the CMS Engine, etc. Thanks, Luca.
The CMS Engine datamodel > page_section needed an additional column for the workflow process run by a specific team, agent or system.
30 minutes thinking, 1 minute coding. Done 😁
Now
Page > Module > Component
Resources
- https://www.infoq.com/articles/adopt-micro-frontends/
- https://en.wikipedia.org/wiki/Conway%27s_law
- https://www.youtube.com/playlist?list=PLQCXBpGR5h_jHo1xbShq3EWOKw38UPCEZ
References
- Reference
Repository
- Home > Ajabbi Research > Library > Subscriptions > InfoQ Weekly Digest
- Home > Handbook >
Last Updated
28/11/2025
Micro-Frontends: A Sociotechnical Journey Toward a Modern Frontend Architecture
Principal Serverless Specialist Solutions Architect @AWS.
Luca Mezzalira is a Principal Solutions Architect and the author of Building Micro-Frontends. He helps organizations design evolutionary architectures and leads modernization programs for global engineering teams. Luca is also the host of the Micro-Frontends in the Trenches podcast, where he explores the future of distributed frontend systems getting deeper into heuristics, pitfalls, and lessons learned from teams that turned this architectural evolution into a competitive advantage. The podcast can be listened to on Spotify, Apple Podcasts or YouTube
- Micro-frontends are different from components. Components are abstraction mechanisms designed for standardisation and reuse, while micro-frontends optimise for autonomy and flow.
- Micro-frontends are not a technical pattern, but a sociotechnical shift mirroring Conway’s law.
- The micro-frontends migration is not a binary decision but a continuum. The migration should start where autonomy brings the most value. The architecture needs to be aligned with the team structure.
- Embrace duplication when it accelerates flow and favours iterative delivery over big rewrites.
- The first micro-frontend should go end-to-end: from design and development through deployment and observability. That vertical slice will surface every challenge you’ll face later - routing, shared dependencies, authentication, monitoring - on a scale that’s still manageable.
For years, distributed systems have defined how we think about backend architecture. We’ve learned to break apart monoliths into independently deployable services, embracing autonomy, faster feedback, and continuous change. But on the frontend, many organisations are still trapped in the same cycle we escaped on the backend: large codebases that slow teams down, coupled deployments that introduce risk, and interfaces so entangled that any change becomes an exercise in fear management.
The rise of micro-frontends is not simply a reaction to this pain; it’s part of a deeper sociotechnical evolution. The same forces that once drove backend modularisation are now reshaping the frontend. As organisations demand faster delivery, greater autonomy, and continuous modernisation, our frontend architectures must evolve in step with our teams.
The distributed frontend era is here, but it’s not defined by new frameworks or fancy tooling. It’s defined by the way we align people, processes, and architecture around a shared goal: delivering value faster without losing control.
In this article, you’ll learn when micro-frontends make sense, how to evolve existing systems safely, and how to handle cross-cutting concerns like routing, state, and user experience without disrupting delivery. The goal is to show how micro-frontends represent not a trend, but a natural sociotechnical evolution.
Rethinking Micro-Frontends
This article focuses on architectural principles rather than any specific framework or vendor solution.
Micro-frontends are often introduced as a technical pattern - a way to break a large frontend into smaller, independently deployable pieces. But that framing misses the point. Micro-frontends are not a new stack; they are a new way of structuring work. They represent a sociotechnical shift - one that mirrors Conway’s Law, which tells us that system design reflects communication structures.
When teams are forced to coordinate through a single release train, decision-making slows. When every change requires syncing across multiple domains, creativity fades. The result is not just technical debt but organisational inertia. Micro-frontends reverse that dynamic. They allow teams to own slices of the product end-to-end - domain, design, delivery - without waiting for centralised approval.
It’s also essential to distinguish micro-frontends from components. Components are a software abstraction mechanism designed to standardise and reuse behaviours or interfaces within a single application or shared ecosystem. They optimise consistency and maintainability. Micro-frontends, instead, maximise independence and flow. They exist to reduce cognitive load, enable teams to make decisions autonomously, and accelerate delivery by removing cross-team dependencies. As a result, micro-frontends operate at a much coarser granularity than components. Where components encapsulate behaviours, micro-frontends encapsulate responsibility, for example, a complete vertical slice of the system owned and operated by a single team.
That autonomy doesn’t come for free. Distributed systems always bring complexity. But when applied thoughtfully, micro-frontends unlock a kind of evolutionary architecture that’s been missing from the client side: the ability to change direction safely and iteratively, at the speed of the business.
When Micro-Frontends Make Sense
Not every system needs to be decomposed. A small product built by a single team can thrive perfectly well with a modular monolith. The signal that you may need micro-frontends is rarely technical - it’s organisational.
If your release cadence slows down as your team grows, if changes in one area routinely break others, if onboarding new engineers feels like navigating an archaeological dig through years of intertwined code - these are the symptoms of a system that has outgrown its structure.
Micro-frontends address this by restoring local autonomy. Each team can ship independently, evolve its stack, and respond to customer needs without waiting for the rest of the organisation to move. The return on investment becomes visible early because, unlike a complete rewrite, migration to micro-frontends is incremental. Each small step delivers value on its own, reducing risk and building confidence.
At one media company I worked with, the shift from a shared frontend to domain-owned micro-frontends reduced coordination effort per release by more than half. Deployment frequency rose tenfold within months. That momentum created the trust needed to continue the migration safely.
But micro-frontends are not a silver bullet. For small teams or products with limited complexity, the overhead might outweigh the benefits. The goal is not to adopt a pattern for its own sake but to solve concrete problems: delivery bottlenecks, scaling limits, and the inability to modernise safely.
Evolving Existing Systems
The hardest part of adopting micro-frontends is not starting fresh; it’s evolving what already exists. Most organisations operate in brownfield environments - large, mature systems that can’t be simply replaced. The challenge is to introduce modularity without breaking everything that works today.
The first principle is to think iteratively. A successful migration doesn’t require shutting down the old world to build the new one. Instead, it uses the old system as scaffolding while gradually introducing new components. Each iteration becomes a slight, measurable improvement - an opportunity to validate assumptions, build new capabilities, and reduce uncertainty.
An iterative approach delivers faster ROI and lowers risk. It allows the business to continue operating while modernisation happens in parallel. It also keeps teams motivated, as each release produces visible progress rather than waiting months for the "big reveal".
From Big Bang to Incremental Change
In backend modernisation, the strangler fig pattern has long been used to gradually replace monolithic systems. The same principle applies beautifully to the frontend. Instead of mixing old and new code in the same pages, route traffic at the edge to decide which version of the application should serve a given request.
By placing routing logic at the CDN or edge layer, you can divert specific paths - say, /checkout or /dashboard - to a new micro-frontend while leaving the rest of the site untouched. If something goes wrong, rollback is instant: just change a routing rule. There’s no need to redeploy or revert code.
Micro-frontends iterative migration with edge-compute
This pattern also unlocks powerful release strategies. You can test new experiences with canary deployments, feature flags, or country-based rollouts, and collect honest feedback before a full release. This iterative rhythm builds trust between technical and business stakeholders. Each deployment becomes both a delivery and a learning opportunity.
The key is to resist the temptation to blend old and new UI within the same page. Mixing rendering systems multiplies complexity and breaks the isolation that makes micro-frontends valuable in the first place. Clear, page-level or route-level boundaries keep the migration safe and reversible.
Planning the Migration
Every migration is a balance between impact and safety. The first module you choose sets the tone for everything that follows. It should be meaningful enough to prove value but isolated enough to minimise risk.
In practice, this often means starting with a new feature or a module already scheduled for major refactoring. That way, the migration effort aligns naturally with business goals - you’re not just modernising for its own sake, you’re enabling new capabilities.
Your first micro-frontend should go end-to-end: from design and development through deployment and observability. That vertical slice will surface every challenge you’ll face later - routing, shared dependencies, authentication, monitoring - on a scale that’s still manageable. The lessons learned there will inform every subsequent migration step.
Think of it as your pilot. If it works, it becomes a reusable template; if it doesn’t, you’ve lost little and gained invaluable insight. Treat migration not as a project but as an ongoing evolutionary process. Each success builds momentum. Each mistake refines your heuristics.
Designing for Modularity
When starting a greenfield project, micro-frontends should align business domains, not technical layers. Instead of organising code by framework or feature type, design independent product capabilities that map to real user needs - catalogue, checkout, profile, analytics.
This domain-driven alignment enables micro-frontends to scale. Each module becomes a boundary between both code and communication. Teams own their space end to end, choosing their technologies, deployment pipelines, and release rhythms. Over time, this reduces coupling not only between systems but between people.
That autonomy requires a contract of trust. Shared guidelines - like how routing works, how design tokens are managed, or how observability is implemented - create coherence without reintroducing central control. The goal is a federation of teams, not anarchy of frameworks.
Evolutionary architecture is not about predicting the future; it’s about being ready for it. Designing change means optimising reversibility. Every decision - tooling, boundary, dependency - should be easy to revisit. The systems that last are those that can adapt, not those that were perfect on day one.
Handling Cross-Cutting Concerns
As with any distributed system, the most complex parts are the seams: routing, authentication, shared state, and user experience. These are the invisible threads that make a product feel cohesive.
Routing is the backbone of your migration. Centralising it at the edge keeps logic out of your application code and simplifies rollback. Using absolute URLs for navigation between systems ensures clarity and predictability. If something breaks, users never land in an undefined state - they’re simply redirected to the stable version.
In practice, this approach turns the edge into a single source of truth for traffic control during the migration period. Instead of embedding conditional logic inside every frontend, edge functions can decide, in milliseconds, whether a request should go to the legacy monolith or to a specific micro-frontend. This also enables progressive rollout strategies, such as canary releases or blue-green deployments, without touching your frontend code.
One of the most valuable advantages is the ability to roll back instantly without polluting your legacy codebase or new micro-frontends with temporary routing hacks. If an issue appears, you simply switch the routing rule at the edge, and all traffic flows back to the stable version. There’s no redeployment, no manual intervention inside the applications, and no need to maintain hybrid rendering layers that mix old and new UI code. The separation between systems remains clean and reversible, which is critical for long-running migrations.
Centralised routing also reduces cognitive load for teams and improves platform stability. Developers no longer need to maintain throwaway routing logic in multiple repositories or synchronise URL patterns between systems. It also simplifies observability, since all incoming requests pass through a single control point that can emit consistent metrics and logs.
Authentication can often be handled more simply than teams expect. As long as all micro-frontends share the same subdomain as the legacy app, they can access the same cookies and session data.
Implementing refreshed token logic in both worlds keeps sessions alive without complex cross-app communication.
State management in micro-frontends should remain local to each application to preserve independence and avoid cross-team coupling. When multiple micro-frontends need to communicate, prefer loosely coupled events that broadcast intent and data where necessary over enforcing shared runtime dependencies. This reinforces architectural boundaries while enabling collaboration where required.
Some configurations, such as authentication tokens, locale, or feature flags, can be shared across systems using stable mechanisms, such as cookies or local storage, or by injecting a lightweight context into each micro-frontend. The key is to keep this shared layer minimal and predictable.
Embracing Duplication (Wisely)
Duplication in distributed systems should never be accidental; it should be intentional. The goal is not to eliminate all repetition but to make conscious decisions about where duplication helps teams move faster and where it introduces unnecessary overhead.
Good heuristics lie at the intersection of complexity and rate of change. For example, a design system evolves quickly during its early phases but stabilises over time. Once mature, its release cycle slows down - nobody changes the design system every day. Similarly, a shared logging library across multiple micro-frontends has low volatility and clear behaviour, so centralising it makes sense. On the other hand, consider a complex video player in a streaming platform. Its heuristics may vary by browser or device to optimise buffering, latency, or startup times. The complexity is high and the rate of change is frequent, so duplication would only multiply maintenance pain without tangible benefits.
Conversely, if you’re dealing with a simple component - say, a basic form of field or small utility - that doesn’t change often and requires minimal effort to implement, feel free to duplicate it. Abstraction can always come later once patterns are proven, and the need for consistency is evident.
Every shared abstraction introduces governance, versioning, and ownership responsibilities. Leaving ownership inside the team responsible for a micro-frontend simplifies the process and preserves autonomy. The best abstractions are those that emerge naturally, not those imposed prematurely. Intentional duplication buys you speed and flexibility; thoughtful consolidation gives you long-term coherence. Balancing the two is what makes distributed architectures evolve gracefully.
The Fastest Path to Modernisation
One of the most persistent myths about micro-frontends is that you need microservices to support them. You don’t. The frontend and backend evolve at different speeds, and the frontend almost always moves faster.
Micro-frontends focus on how teams build and deliver interfaces, not on how data is served. As long as you have stable API contracts, your frontend can modernise independently of your backend. You can keep your monolithic APIs while introducing modular frontends on top of them. The stateless nature of frontends makes them ideal for incremental modernisation.
Backend migrations are often lengthy because data has gravity. Schema changes, replication strategies, and legacy dependencies can stretch timelines for months or years. Frontend migrations, by contrast, can deliver visible value in weeks. You can start improving performance, maintainability, and user experience immediately, without waiting for backend modernisation to catch up.
At a retail company I advised, the frontend migration to micro-frontends was completed in roughly 14 months. The backend modernisation took twice as long, but the organisation saw immediate value early on through faster releases and a better user experience, even while the backend was still monolithic.
The frontend can lead the way, serving as a proving ground for distributed practices and a catalyst for broader organisational change.
Modernisation at Human Speed
Modernisation is not a single event; it’s a journey. The temptation to start over is strong, especially when legacy systems feel immovable. But the "big bang" approach rarely succeeds. It freezes business progress, drains morale, and often ends in partial rewrites that never reach production.
Micro-frontends offer a different path, one that aligns with how organisations truly evolve. They let you move at human speed: fast enough to show progress, slow enough to stay safe. They encourage experimentation, continuous learning, and local ownership.
Every migration is a balancing act between ideal architecture and practical delivery. The teams that succeed are those that accept imperfections as part of the process. They know that good architecture is not about purity; it’s about flow.
If there’s a guiding principle to remember, it’s this: evolutionary beats revolutionary. Iterate, learn, and adapt. The systems you build today will change tomorrow, and that’s a feature, not a flaw.
For teams exploring this path, the distributed frontend era is not about frameworks or bundlers. It’s about designing systems and organisations that can evolve continuously, safely, and with purpose.
Conclusion
Micro-frontends are more than a technical pattern; they reflect how modern organisations build software. They embody the shift from centralised control to distributed ownership, from significant releases to continuous flow, from architectural rigidity to evolutionary change.
By approaching migration iteratively - starting small, learning fast, and keeping business goals at the centre - you can modernise your frontend without halting innovation. Whether your backend is still monolithic or already distributed doesn’t matter. What matters is your ability to evolve safely and deliver value continuously.
Architecture, at its best, mirrors the way people collaborate. When teams are empowered, systems follow. Micro-frontends are simply the architectural expression of that truth.
