What Is Micro-Frontend Architecture?
Learn what micro-frontend architecture is, composition strategies, and the real tradeoffs of splitting a frontend by team.
Expected Interview Answer
Micro-frontend architecture splits a large web application into independently built, tested, and deployed frontend units — often owned by separate teams — that are composed together at runtime or build time into a single cohesive user experience.
Each micro-frontend typically owns a vertical slice of functionality (say, checkout, search, or account settings) with its own codebase, release pipeline, and sometimes its own framework version, mirroring how microservices split backend ownership. Composition can happen at build time (bundling separate packages into one app), at runtime in the browser via techniques like Module Federation or iframes, or at the edge/server via server-side includes. The main win is independent deployability — one team can ship a change to checkout without coordinating a release with the team that owns search — but it introduces real costs: duplicated framework runtime bytes unless carefully shared, harder cross-team UX/design consistency, and more complex integration testing since the composed app only truly exists at runtime. Teams should only reach for micro-frontends when organizational scale (many independent teams shipping on different cadences) justifies the added operational complexity; a single team on one codebase rarely benefits.
- Independent deployability lets teams ship without cross-team release coordination
- Enables incremental technology/framework migration one slice at a time
- Clear ownership boundaries mirror team structure (Conway's Law aligned)
- Failure isolation — one broken micro-frontend need not take down the whole shell
AI Mentor Explanation
Micro-frontend architecture is like a stadium where different vendors independently run the scoreboard, the food stalls, and the ticket gates, each upgrading their own equipment on their own schedule without asking the others for permission. The stadium operator just provides a shared shell — power, space, signage — that lets all these independent operations appear as one coherent venue to the fans. If the food stall vendor swaps out their point-of-sale system, ticketing keeps running unaffected. That independently-owned-slices-composed-into-one-experience model is exactly what micro-frontend architecture does with a web application.
Step-by-Step Explanation
Step 1
Define ownership boundaries
Split the app into vertical slices (e.g., checkout, search) that map to independent team ownership.
Step 2
Choose a composition strategy
Pick build-time bundling, runtime composition (Module Federation, iframes), or server-side/edge composition.
Step 3
Build the shared shell
A thin host app handles routing, layout, and shared concerns (auth, design tokens) that every micro-frontend plugs into.
Step 4
Deploy micro-frontends independently
Each team ships its slice on its own pipeline; the shell picks up the new version at the next composition point.
What Interviewer Expects
- Understanding of independent deployability as the core motivating benefit
- Awareness of composition strategies: build-time, runtime (Module Federation), server-side
- Ability to name real costs: duplicated runtime bytes, UX consistency, integration testing complexity
- Judgment on when NOT to use micro-frontends (small single-team apps)
Common Mistakes
- Recommending micro-frontends for a single small team with one codebase
- Ignoring duplicated framework/runtime bytes when each micro-frontend ships its own React copy
- Not addressing cross-team design/UX consistency as a real ongoing cost
- Confusing micro-frontends with simply splitting a monolith into multiple pages/routes
Best Answer (HR Friendly)
“Micro-frontend architecture means breaking a large web app into smaller pieces that different teams build and release independently, then bringing them together into one experience for the user, similar to how backend teams split services into microservices. It is powerful for large organizations with many teams shipping on different schedules, but it adds real complexity, so I would only recommend it once a team clearly outgrows a single shared codebase.”
Code Example
// host/webpack.config.js
const ModuleFederationPlugin = require('webpack/lib/container/ModuleFederationPlugin')
module.exports = {
plugins: [
new ModuleFederationPlugin({
name: 'shell',
remotes: {
checkout: 'checkout@https://checkout.acme.com/remoteEntry.js',
},
shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
}),
],
}
// host/src/App.jsx
import { lazy, Suspense } from 'react'
const CheckoutFlow = lazy(() => import('checkout/CheckoutFlow'))
export function App() {
return (
<Suspense fallback={<div>Loading checkout...</div>}>
<CheckoutFlow />
</Suspense>
)
}Follow-up Questions
- How does Module Federation share singleton dependencies like React across micro-frontends?
- How would you keep design-system consistency across independently deployed micro-frontends?
- What is the difference between build-time and runtime micro-frontend composition?
- How would you handle shared authentication state across micro-frontends owned by different teams?
MCQ Practice
1. What is the primary organizational motivation for micro-frontend architecture?
The core motivation is independent deployability aligned with team ownership boundaries, not raw performance.
2. What is a common real cost of micro-frontend architecture?
Without careful dependency sharing (e.g., Module Federation singletons), each micro-frontend can ship its own copy of React.
3. Which technique enables runtime composition of separately deployed micro-frontends?
Module Federation lets a host app dynamically load remote bundles built and deployed independently at runtime.
Flash Cards
What is a micro-frontend? — An independently built, tested, and deployed slice of a web app, often owned by one team.
Main micro-frontend benefit? — Independent deployability without cross-team release coordination.
Main micro-frontend cost? — Duplicated runtime bytes and harder cross-team UX consistency.
Name a runtime composition technique. — Webpack Module Federation, dynamically loading remote bundles in the browser.