During his QCon London presentation, Luca Mezzalira, principal architect at AWS, shared his experience in building the ideal micro frontend platform. He disclosed the recipe for determining if micro frontends are right for your company, as well as the core principles of creating the perfect architecture for your use case, and also provided deployment strategies for distributed architectures.
He began his presentation by recalling how he first conceptualised micro-frontends while working on a sports streaming service, emphasising the developer’s reluctance (“Does this guy know what he’s talking about?”) when he presented them with the definition:
Mezzalira: Micro-frontends are the technical representation of a business subdomain. They allow independent implementation with the same or different technology.
Finally, they should minimise the code shared and owned by other subdomains owned by a single team.
Next, he introduced a set of heuristics to ensure that developers remain in the microfrontends frame and to differentiate it from a component. While components expose numerous properties for reuse and are controlled by their container, microfrontends encapsulate their domain knowledge and state, offering a minimal API to optimise for team autonomy rather than reusability.
Neil Ford: Reuse is a form of coupling
Heuristics:
- Reduce APIs that are exposed to the container (typically having 1-2 APIs or properties maximum)
- Microfrontends are context-aware (the state lives inside the microfrontend, not outside it)
- Don’t optimise for reusability at all costs (the goal is fast flow, not reusability)
- They are more coarse-grained than components (“if you have 25 runtime microfrontends, you’re likely dealing with a distributed monolith”)
He emphasised that microfrontends evolve with the business itself ( “… [microfrontend] boundaries are not forever”), adapting to the structural changes. Mezzalira pointed to Conway’s Law and team topologies to underscore the changes occurring in organisations, transitioning from hierarchical to more distributed and autonomous units. The organisational benefits of a well-implemented microfrontend include incremental upgrades, faster feedback loops for critical features, reduced team cognitive load, and the ability to scale both technology and organisation in harmony.
To guide the developers’ design decisions, he presented his decision framework:
- Identify: How to split the frontend – choosing between horizontal split (by UI sections like header, product details) or vertical split (by pages or groups of pages)
- Compose: Deciding between client-side composition (using an application shell) or server-side composition (composing rendered fragments)
- Routing: Determining how routing will work – typically handled by the application shell
- Communicate: Choosing how microfrontends will communicate with each other (event emitter, custom events, or reactive streams, with event emitter being recommended)
He underscored that these four points are always present in any microfrontend architecture, regardless of whether it uses server-side, client-side, or edge-side rendering. Every team implementing microfrontends must make decisions about these four aspects. However, as we also need to implement them, Mezzalira advised: “Don’t start with technology selection”—first understand what your architecture needs to express and your specific context constraints. The framework choice should align with your requirements, not dictate them. To further emphasise the importance of choosing technologies wisely, he referred to the microfrontend anarchy antipattern coined by Thoughtworks in their Technology Radar.
Mezzalira: “It’s not the framework that you need to select, it’s the context that you need to understand.”
The platform team should own the app shell and keep it as vanilla as possible. It should remain context-aware, expose only initial configuration, and handle routing and composition while staying incredibly lightweight. Changes to microfrontends should never require modifications to the shell, as this indicates poorly defined boundaries where domain knowledge is leaking.
Deployments are one of the most crucial aspects to consider when designing a distributed system. Microfrontend deployments should be incremental, frequent, and independent, leveraging discovery services with version management to enable seamless canary releases, targeted rollouts, and instant rollbacks without rebuilding—putting deployment control directly in teams’ hands while maintaining user experience consistency. To standardise this approach, he worked together with the owners of the most adopted microfrontend frameworks. The result of their working group was the front-end discovery schema, as well as a front-end discovery service, which enables the use of any continuous integration tool to deploy microfrontends.
Successful microfrontend implementation requires a clear understanding of team ownership boundaries, platform responsibilities, value stream ownership, fast feedback loops, and a decentralised mindset—addressing these aspects prevents the common failures seen even in mature teams attempting this architecture. To conclude, Mezzalira recommended shifting left from the continuous integration pipeline to a place where developers can iterate quickly. Aspects such as performance, footprint, and even security need to be addressed as early as possible.
