Micro-Frontends Interview Questions: Architecture, Trade-offs, Patterns (2026)

Micro-frontends interview questions are architecture questions. A micro-frontend is an independently deliverable frontend slice, usually owned by one team, that is composed with other slices into one product. The interviewer is checking whether you can split frontend ownership without creating a slower, less consistent, harder-to-debug product.

The answer should not start and end with Module Federation. A good answer covers ownership boundaries, composition, shared dependencies, routing, design systems, observability, rollback, and user experience.

For current implementation vocabulary, use webpack Module Federation docs, single-spa microfrontends guide, and MDN import maps reference. Treat tools as options; the architecture decision comes before the bundler choice.

What interviewers are testing

Questions and model answers

1. When should a team consider micro-frontends?

Consider them when frontend ownership is already split across teams and release coordination is a bottleneck. They are most useful when product domains can be owned and deployed independently without breaking user journeys.

Good answer shape:

• Start with team and product boundaries.
• Name the release problem being solved.
• Say a modular monolith may be simpler when one team owns the app.

Common mistake: Choosing micro-frontends because the codebase feels large, before trying module boundaries, design-system discipline, or build improvements.

2. What are common composition patterns?

Common patterns include route-level composition, component-level runtime composition, iframes for isolation, Web Components for framework boundaries, and server-side composition. Each changes routing, performance, styling, and failure behavior.

Good answer shape:

• List at least three patterns.
• Explain one tradeoff per pattern.
• Tie the choice to a product scenario.

Common mistake: Treating all micro-frontends as remote React components loaded by one host.

3. How does Module Federation help?

Module Federation lets separately built applications expose and consume modules at runtime. It can support independent deployment, but teams still need version contracts, shared dependency rules, error boundaries, and rollout strategy.

Good answer shape:

• Define host, remote, exposed modules, and shared dependencies.
• Mention runtime loading and version rules.
• Add operational caveats.

Common mistake: Assuming Module Federation automatically gives safe independent deploys.

4. How do you avoid duplicate React or design-system code?

Define shared dependency policy, compatible version ranges, and a design-system release process. Some teams share runtime dependencies; others isolate more strongly. The important part is measuring duplication and avoiding mismatched component behavior.

Good answer shape:

• Mention dependency policy and measurement.
• Discuss design tokens and component APIs.
• Name the risk of inconsistent accessibility behavior.

Common mistake: Sharing everything globally without ownership, or sharing nothing and shipping three versions of every core library.

5. How should routing work?

The shell should own top-level navigation and route ownership. Each micro-frontend can own internal routes within its domain, but the URL contract, auth redirects, analytics, and not-found behavior need shared rules.

Good answer shape:

• Separate shell routes from domain routes.
• Mention URL contracts and auth.
• Discuss cross-app navigation and fallback routes.

Common mistake: Letting every remote mutate global routing state in incompatible ways.

6. How do micro-frontends affect performance?

They can improve initial load if domain code is split and loaded only when needed. They can also hurt performance through runtime waterfalls, duplicate dependencies, larger shells, and slower cross-app boundaries.

Good answer shape:

• Say they are not automatically faster.
• Mention preloading, caching, and bundle analysis.
• Discuss field metrics after rollout.

Common mistake: Selling team autonomy while ignoring the user's loading and interaction cost.

7. How do you handle failures?

Use error boundaries, remote load fallbacks, health checks, version rollback, and clear ownership. If one remote fails, the shell should preserve navigation and show a useful failure state for that domain.

Good answer shape:

• Name remote load failure separately from render failure.
• Mention fallback UI and incident ownership.
• Include rollback and monitoring.

Common mistake: Letting a failed remote crash the whole shell without a recovery path.

8. How do you keep UX consistent?

Use shared tokens, component standards, accessibility rules, analytics naming, content patterns, and review gates for cross-domain flows. Consistency is a governance problem as much as a package problem.

Good answer shape:

• Mention design system and tokens.
• Include accessibility and content states.
• Explain governance without centralizing every deploy.

Common mistake: Assuming a shared component library alone prevents inconsistent product behavior.

9. How should data and backend communication work?

Keep data ownership aligned with product ownership. The shell may provide session, locale, feature flags, and top-level auth handoff, but domain data should usually come from the owning micro-frontend or its backend contract. If multiple remotes need the same data, define the source of truth, cache rules, event contract, and compatibility window.

Good answer shape:

• Separate session context from domain state.
• Mention BFFs, API contracts, typed events, or route state as options.
• Explain how contract changes stay backward compatible during independent deploys.

Common mistake: Putting every shared value into a global client store until the remotes are no longer independently deployable.

10. How do SSR, SEO, and server composition fit?

Micro-frontends do not have to be client-only. Content-heavy routes may use server-side or edge composition so crawlers and users receive meaningful HTML early. Interactive domains can still hydrate independently, but the team needs rules for data bootstrapping, streaming, caching, error boundaries, and what happens when one fragment fails.

Good answer shape:

• Match rendering strategy to the route: public content, logged-in app, dashboard, or checkout.
• Discuss server composition, client composition, and hydration boundaries.
• Name the performance and failure tradeoff.

Common mistake: Assuming Module Federation is the only implementation model, even for SEO-sensitive pages.

11. How do you handle security and isolation?

Use the isolation level that matches the trust boundary. Internal product remotes may share auth context through a narrow shell contract, while less-trusted or third-party UI may need iframe isolation, strict messaging, CSP, sandboxing, and separate origins. Validate cross-app events and avoid exposing long-lived tokens through globals.

Good answer shape:

• Separate trusted internal remotes from untrusted embedded UI.
• Mention CSP, iframe sandboxing, origin boundaries, and token handling when relevant.
• Explain how security rules affect UX, debugging, and performance.

Common mistake: Treating every micro-frontend as equally trusted because it appears inside the same product shell.

How to practice

Practice by designing a migration, not a blank-slate architecture. Most micro-frontend interviews ask how to move a large app safely.

• Split an e-commerce app into shell, catalog, cart, checkout, and account domains; define route ownership.
• Explain how a remote checkout failure should appear to users and to on-call engineers.
• Compare Module Federation, iframe isolation, and server-side composition for an admin dashboard.
• Read Web Apps at Scale: Introduction and map the same concerns to micro-frontends.

Common weak answers

These answers sound prepared, but they do not give the interviewer enough signal. Rewrite them into specific engineering decisions.

Extended question bank

Use these as spoken practice. A complete answer should be specific enough that another engineer can tell what you would inspect, change, and verify.

1. When would you not use micro-frontends?

Avoid them when one team owns the UI, deployment coordination is simple, shared design is more important than independent releases, or the runtime cost would outweigh team autonomy. A good answer shows restraint: micro-frontends are an organizational tool with technical cost.

2. What belongs in the shell?

The shell usually owns routing, layout frame, global navigation, auth context, shared observability, error boundaries, and remote loading policy. It should not become a dumping ground for product logic. Keep the shell stable and boring.

3. How do teams share a design system?

Use shared tokens, accessible primitives, documented component APIs, versioning, visual regression, and migration guides. Teams can own product features independently while still sharing interaction standards and brand constraints.

4. How do you test across independently deployed apps?

Use contract tests for shared APIs and events, component tests inside each app, smoke tests for shell integration, and monitoring for remote load failures. Add rollback and compatibility windows because independent deployment does not remove integration risk.

5. How do you avoid dependency duplication?

Set a shared dependency policy, monitor bundles, avoid casual framework mixing, and plan upgrades. Module Federation can share dependencies, but runtime compatibility and version policy still need ownership.

Answer depth by level

Mini case studies

Splitting checkout from a retail monolith

Checkout is a reasonable candidate because the business domain is clear and the release risk is high. The shell can own navigation, auth, and global layout while checkout owns its route, form states, payment provider integration, and error handling. The migration should keep the old route behind a flag, compare conversion and performance, and define rollback before traffic moves.

Remote dashboard widget fails

Treat remote load failure differently from render failure. If the remote entry cannot load, the shell should show a domain-specific fallback and log the version, route, and remote URL. If rendering throws, use an error boundary around the widget so the rest of the dashboard remains usable. In both cases, decide who is paged before the incident happens.

Shared dependency drift

If three remotes ship different React or design-system versions, first measure bundle and runtime behavior. Then decide whether the drift is temporary during an upgrade, intentional isolation, or unmanaged duplication. The fix may be a shared dependency policy, not a bigger Module Federation config.

Advanced follow-up answers

What should not go into the shell?

The shell should not accumulate domain logic just because multiple teams need it. Keep product rules, domain state, and feature-specific UI in the owning micro-frontend. The shell should stay stable: routing frame, auth/session handoff, global layout, observability, remote loading, and shared failure policy.

How do teams communicate across micro-frontends?

Use the smallest contract that preserves ownership. Route parameters, URL state, typed custom events, shared services, or backend APIs can work depending on the boundary. Avoid casual global stores that make independent deploys fictional.

How do you handle shared state?

Shared state should be rare and explicit. Session, locale, feature flags, and design tokens may be shell-provided. Domain state should stay with the owning app or server. If every remote needs to mutate the same client store, the boundary is probably wrong.

How do you test contracts?

Test API schemas, shared events, route contracts, design-system versions, and shell integration separately. Add smoke tests for critical user journeys because independent deployment increases the chance that two correct pieces break together.

How do you avoid CSS conflicts?

Use shared tokens and components for consistency, and use scoping strategies for isolation when teams ship independently. CSS Modules, Shadow DOM, naming rules, or build-time scoping can help, but design governance still matters.

How do you roll back safely?

Version remotes, keep compatibility windows, use feature flags where needed, and know whether rollback happens in the shell, remote, CDN, or deployment platform. A good answer names who owns the rollback before a production incident.

How do micro-frontends affect accessibility?

They can fragment accessibility if every team implements focus, modals, forms, and announcements differently. Shared primitives, review checklists, and cross-app smoke tests keep the product coherent for keyboard and assistive-technology users.

What metric proves micro-frontends helped?

Measure deployment frequency, lead time, rollback frequency, integration incidents, bundle cost, user metrics, and developer onboarding. If team autonomy improves but user experience gets worse, the architecture is not a success yet.

Worked example: splitting a large dashboard

Imagine a company has one large dashboard owned by four teams. Releases are slow because every team must coordinate in the same frontend repo. Micro-frontends might help, but only if the split follows ownership boundaries and the runtime cost is acceptable.

Use this sequence:

1. Identify domain boundaries such as billing, reporting, account settings, and admin tools.
2. Prefer route-level ownership before embedding many cross-team components.
3. Define what the shell owns: auth, navigation, layout, telemetry, and remote-loading policy.
4. Set a shared design-system and dependency policy before teams diverge.
5. Add fallback behavior for a failed remote and alert the owning team.
6. Plan migration one route at a time with rollback.

A strong answer says: "I would not split by arbitrary components. I would split by product domain, keep shared navigation in the shell, and require each remote to own its tests, monitoring, and fallback. I would also measure bundle duplication because micro-frontends can make the user experience worse if dependency policy is loose."

Do not sell micro-frontends as an automatic upgrade. The answer should show what problem they solve and what new problems they create.

Micro-frontends are a coordination tool. The interview answer should show when the coordination benefit is worth the runtime and governance cost.