Roadmap/Track Detail
Article Guide
Architect18 min readJune 13, 2026

Micro Frontend Interview Questions and Answers

Prepare for senior frontend and frontend architect interviews with micro frontend questions covering architecture, Module Federation, routing, auth, state, testing, deployment, performance, and system design.

Tags:
Micro FrontendsInterview QuestionsFrontend ArchitectureSystem DesignModule FederationInterview Prep

Micro frontends are a common topic in senior frontend, frontend lead, and frontend architect interviews.

But interviewers rarely ask only:

textEditor
What are micro frontends?

They usually go deeper:

textEditor
When would you use them?
When would you avoid them?
How do you design the shell?
How do remotes communicate?
How do you handle routing?
How do you handle authentication?
How do you avoid duplicate React?
How do you test independent deployments?
What happens if one remote fails?
How do you deploy and roll back safely?

This article gives you interview-ready answers from beginner level to architect level.

The goal is not memorization.

The goal is to help you explain micro frontends like a senior engineer who understands tradeoffs.

1. How to Answer Micro Frontend Questions

A strong answer should include four things:

textEditor
Definition
Problem solved
Tradeoffs
Production concerns

Weak answer:

textEditor
Micro frontends mean splitting frontend into multiple apps.

Strong answer:

textEditor
Micro frontends split a large frontend into independently owned and independently deployable domain applications. They help large teams move independently, but they add complexity around routing, shared dependencies, testing, deployment, observability, and failure isolation.

That difference matters.

2. Beginner Questions

Q1. What are micro frontends?

Micro frontends are an architectural pattern where a large frontend application is split into smaller, independently owned frontend applications.

Each micro frontend usually represents a business domain.

Example:

textEditor
Catalog Remote
Cart Remote
Checkout Remote
Profile Remote
Orders Remote

These are composed together by a shell or host app to create one user experience.

Strong answer:

Micro frontends are like microservices for the frontend, but the main goal is not just splitting code. The real goal is independent ownership, independent deployment, and domain-level autonomy for large frontend teams.

Q2. Why do companies use micro frontends?

Companies use micro frontends when one frontend monolith becomes difficult for many teams to work on together.

Common reasons:

textEditor
Large frontend codebase
Slow build and test pipeline
Many teams blocked by one release cycle
Unclear ownership
Difficult migration from old technology
Need for independent deployment

Good answer:

Micro frontends are useful when team scale and release independence become bigger problems than code organization.

Q3. Are micro frontends only about performance?

No.

Micro frontends are mainly about:

textEditor
Team ownership
Independent deployment
Domain boundaries
Incremental migration
Release autonomy

They can improve performance if implemented with route-level lazy loading and shared dependency governance.

But they can also hurt performance if every remote ships duplicate dependencies or creates runtime loading waterfalls.

Strong phrase:

Micro frontends do not automatically improve performance. They improve ownership and deployment autonomy. Performance still needs deliberate design.

Q4. What is a shell app?

The shell app is the host or container application that composes micro frontends into one product.

The shell usually owns:

textEditor
Global layout
Top-level routing
Authentication bootstrap
Remote loading
Error boundaries
Fallback UI
Feature flag bootstrap
Analytics initialization

The shell should not own domain business logic.

Strong answer:

The shell coordinates the experience. It should not become the new frontend monolith.

Q5. What is a remote app?

A remote app is an independently built and deployed frontend application that owns a specific domain.

Example:

textEditor
Cart Remote owns cart UI and cart behavior.
Checkout Remote owns checkout flow.
Profile Remote owns profile pages.

A remote can be loaded by the shell at runtime.

Strong answer:

A remote owns domain UI and behavior. It should be independently testable, deployable, observable, and rollback-safe.

3. Intermediate Questions

Q6. What is Module Federation?

Module Federation is a webpack feature that allows one JavaScript application to load code from another independently built application at runtime.

In micro frontends, it is commonly used to let a shell app load remote apps.

Important concepts:

textEditor
Host
Remote
remoteEntry.js
Exposes
Shared dependencies
Singleton dependencies

Strong answer:

Module Federation enables runtime composition, where the shell can load remote modules without rebuilding the full application.

Q7. What is remoteEntry.js?

remoteEntry.js is the runtime entry file exposed by a remote application.

It tells the host:

textEditor
Which modules the remote exposes
How to load those modules
What shared dependencies are required
Where chunks can be loaded from

Example:

textEditor
cartApp/remoteEntry.js

The shell loads this file to access something like:

textEditor
cartApp/CartPage

Strong answer:

remoteEntry.js is the handshake file between host and remote.

Q8. What is the difference between build-time and runtime composition?

Build-time composition

All code is combined during build.

textEditor
App imports package.
Build creates one artifact.
Deployment happens together.

Runtime composition

The shell loads remote code at runtime.

textEditor
Shell loads remoteEntry.js.
Remote code is fetched dynamically.
Remote can deploy independently.

Strong answer:

Build-time composition is simpler, but runtime composition gives more deployment independence.

Q9. What are exposed modules?

Exposed modules are the modules a remote makes available to the shell.

Example:

textEditor
Cart Remote exposes:
./CartPage
./CartDrawer
./MiniCart

The shell can then load those modules.

Important:

Exposed modules are part of the remote contract. Changing them can break the shell.

Q10. What are shared dependencies?

Shared dependencies are libraries that the shell and remotes agree to share instead of bundling separately.

Common examples:

textEditor
React
React DOM
Design system
Auth SDK
Analytics SDK

React and React DOM are often shared as singletons to avoid multiple React instances.

Strong answer:

Shared dependencies reduce duplication, but they need governance. Sharing too much creates coupling.

4. Architecture Questions

Q11. How would you design a micro frontend architecture for an e-commerce platform?

A strong architecture:

textEditor
Shell App
├── Home Remote
├── Catalog Remote
├── Product Details Remote
├── Cart Remote
├── Checkout Remote
├── Profile Remote
└── Orders Remote

The shell owns:

textEditor
Global layout
Top-level routing
Auth bootstrap
Remote loading
Error boundaries
Feature flags
Analytics

Each remote owns its domain.

Example:

textEditor
Catalog Remote → category pages, filters, sorting
Cart Remote → cart page, quantity updates
Checkout Remote → address, delivery, payment, review
Orders Remote → order history and order details

Strong answer:

I would split by business domain, not by UI widgets. Each remote should have clear ownership, independent CI/CD, contract tests, fallback UI, observability, and rollback support.

Q12. How do you decide micro frontend boundaries?

Good boundaries follow business domains.

Good examples:

textEditor
Catalog
Cart
Checkout
Orders
Profile
Search

Bad boundaries:

textEditor
Button
Header text
Product image
Small filter component
Price label

Decision checklist:

textEditor
Can one team own it?
Can it deploy independently?
Can it be tested independently?
Does it have clear route ownership?
Does it have limited communication with other domains?
Can it fail without breaking the whole app?

Strong phrase:

A good micro frontend boundary is an ownership boundary, not just a component boundary.

Q13. What should the shell own?

The shell should own platform-level concerns:

textEditor
Global layout
Top-level routing
Auth bootstrap
Remote loading
Fallback UI
Error boundaries
Feature flag initialization
Analytics initialization
Theme and locale providers
Remote manifest loading

It should not own:

textEditor
Cart calculations
Checkout rules
Product filtering logic
Payment behavior
Order business rules
Domain API logic

Strong answer:

The shell should coordinate composition, not own business logic.

Q14. What should remotes own?

Remotes should own domain-specific UI and behavior.

Example:

textEditor
Catalog Remote owns filters, sorting, category listing.
Cart Remote owns cart UI and cart interactions.
Checkout Remote owns checkout steps and validation UX.
Profile Remote owns profile pages and account settings.

Remotes should own:

textEditor
Domain components
Domain routes
Domain API calls
Domain state
Domain tests
Domain observability
Domain deployment

Strong answer:

A remote should be independently owned, independently deployable, and independently observable.

Q15. How do micro frontends communicate?

Prefer communication methods that keep remotes loosely coupled.

Recommended:

textEditor
URL state
Backend APIs
Small custom events
Shell-mediated platform context
Event bus with strict contracts

Avoid:

textEditor
Direct remote-to-remote imports
Shared global store for everything
Reading hidden localStorage keys
Mutating another remote’s state

Strong answer:

Communication should happen through explicit contracts, not private implementation details.

5. Routing Questions

Q16. Who owns routing in micro frontends?

Usually:

textEditor
Shell owns top-level routing.
Remotes own nested domain routing.

Example:

textEditor
Shell:
/checkout/* → Checkout Remote

Checkout Remote:
/checkout/address
/checkout/delivery
/checkout/payment
/checkout/review

Strong answer:

The shell owns route selection. The remote owns route interpretation.

Q17. How do you support deep linking?

Deep linking means direct URLs should work.

Example:

textEditor
/profile/addresses

Flow:

textEditor
Server returns shell app.
Shell matches /profile/*.
Shell loads Profile Remote.
Profile Remote renders Addresses page.

Important:

textEditor
Hosting/server must fallback to shell index.html for client-side routes.

Strong answer:

Deep links work when the shell can route directly to the correct remote and the remote can interpret its nested path.

Q18. How do you avoid route conflicts?

Use:

textEditor
Central route registry
Route ownership documentation
Route naming conventions
CI validation
Platform review for top-level routes

Example:

textEditor
/categories/* → Catalog Remote
/product/:id → Product Remote
/cart → Cart Remote

Avoid overlapping ownership.

Strong answer:

Every route should have exactly one owner.

6. Authentication and Authorization Questions

Q19. Where should authentication live?

Authentication bootstrap usually belongs in the shell or platform layer.

The shell can own:

textEditor
Session bootstrap
Login/logout
Token refresh orchestration
Protected route checks
Redirect after login
Identity context

Remotes consume safe identity context.

Strong answer:

Authentication should be centralized for consistency. Remotes should not each implement their own login flow.

Q20. Where should authorization live?

Authorization should happen at multiple levels.

textEditor
Shell → broad route protection
Remote → feature-level permission UX
Backend → real security enforcement

Example:

textEditor
Shell checks if user is logged in for /orders.
Orders Remote checks if user can view this order.
Orders API enforces ownership.

Strong answer:

Frontend authorization improves UX, but backend authorization protects the system.

Q21. Should remotes access tokens directly?

Ideally no.

Better:

textEditor
Shell/auth provider manages session.
Approved API layer attaches credentials.
Remotes call domain APIs.
Tokens are not passed through props, events, URLs, or localStorage.

Strong answer:

Token handling should be centralized and secure. Spreading token logic across remotes creates security and consistency problems.

7. State Management Questions

Q22. Should micro frontends share one global store?

Usually no.

A shared global store creates tight coupling.

Bad:

textEditor
Catalog writes global state.
Cart reads catalog state.
Checkout mutates cart state.
Profile depends on checkout state.

Better:

textEditor
Shell owns platform state.
Remotes own domain state.
Backend owns business-critical state.
URL owns shareable route state.

Strong answer:

Sharing a state library is okay. Sharing one global store across all remotes is usually risky.

Q23. Where should cart state live?

For e-commerce, cart state is business-critical.

Recommended:

textEditor
Backend/API owns source of truth.
Cart Remote owns cart UI state.
Shell may show cart badge from a small cart summary.
Other remotes communicate through events or API updates.

Example:

textEditor
Product Remote adds item.
Cart API updates cart.
Cart Remote/Header gets updated summary.

Strong answer:

Cart is too important to live only in frontend memory. Backend should be the source of truth.

Q24. When should URL state be used?

Use URL state for shareable route-level state.

Examples:

textEditor
Search query
Filters
Sorting
Pagination
Selected tab
Category slug
Product ID

Avoid URL state for:

textEditor
Tokens
Payment data
Full cart object
Private user data
Large JSON payloads

Strong answer:

URL state is ideal for navigation and shareable state, not sensitive or complex application state.

8. Testing Questions

Q25. How do you test micro frontends?

Use multiple layers:

textEditor
Unit tests inside each remote
Component tests
Contract tests
Shell + remote integration tests
E2E tests for critical journeys
Visual regression tests
Performance checks
Deployment smoke tests
Production monitoring

Strong answer:

Unit tests prove a remote works alone. Contract and integration tests prove it works inside the product.

Q26. What is contract testing in micro frontends?

Contract testing verifies that shell and remotes agree on integration points.

Contracts include:

textEditor
Exposed modules
Props
Events
Event payloads
Routes
Shared dependency expectations
Feature flags

Example:

textEditor
Cart Remote must expose ./CartPage.
CartPage must accept userId, locale, currency.
Cart Remote must emit cart:updated with itemCount.

Strong answer:

Contract tests protect independent deployment.

Q27. What E2E tests are important?

Test critical user journeys across remotes.

Examples:

textEditor
Search → Product Details → Add to Cart → Checkout
Login → Orders
Profile address update → Checkout address selection
Cart quantity update → Checkout total update

Do not test every small UI detail with E2E.

Strong answer:

E2E tests should focus on cross-remote business-critical journeys.

9. Deployment and Rollback Questions

Q28. How do you deploy micro frontends independently?

Each remote should have its own CI/CD pipeline.

Example:

textEditor
Cart Repo → Build → Test → Publish versioned artifact → CDN → Update manifest

The shell loads remotes through:

textEditor
remoteEntry.js
Remote manifest
Versioned URLs

Strong answer:

Independent deployment is safe only when contracts, smoke tests, observability, and rollback are in place.

Q29. What is a remote manifest?

A remote manifest maps remote names to active versions and URLs.

Example:

jsonEditor
{
  "cartApp": {
    "version": "1.8.4",
    "url": "https://cdn.company.com/cart/1.8.4/remoteEntry.js",
    "rollbackVersion": "1.8.3",
    "owner": "cart-team"
  }
}

Benefits:

textEditor
Controlled rollout
Rollback
Version visibility
Environment promotion
Canary release

Strong answer:

A manifest gives runtime flexibility without blindly loading the latest remote.

Q30. How do you roll back one micro frontend?

Keep previous versions available and switch the manifest back.

Example:

textEditor
cartApp v1.8.5 fails.
Manifest points back to cartApp v1.8.4.
Shell loads stable version.
Cart team investigates v1.8.5.

Strong answer:

A remote rollback should not require redeploying the entire shell unless the shell itself is broken.

10. Performance Questions

Q31. How do you optimize micro frontend performance?

Use:

textEditor
Lightweight shell
Route-level lazy loading
Controlled preloading
React singleton
Shared dependency governance
Bundle budgets per remote
Versioned caching
Skeleton UI
Web Vitals monitoring per route and remote

Strong answer:

Micro frontend performance is not automatic. It requires governance across loading, dependencies, caching, and monitoring.

Q32. How do you avoid duplicate React bundles?

Configure React and React DOM as shared singleton dependencies and enforce version policy.

Also monitor bundles in CI.

Strong answer:

React should usually be shared as a singleton, but singleton must be combined with version governance.

Q33. How do you prevent layout shift when remotes load?

Use:

textEditor
Stable shell layout
Reserved content space
Skeletons matching final dimensions
Defined image dimensions
Early CSS loading
Avoid late layout-changing styles

Strong answer:

Async remote loading should not cause the page to jump.

11. Failure Isolation Questions

Q34. What happens if one remote fails?

The shell should remain stable.

Expected behavior:

textEditor
Remote fails.
Shell catches failure.
Fallback UI appears.
Navigation remains usable.
Error is logged with remote name/version.
Owning team is alerted.
Rollback is possible.

Strong answer:

Micro frontends are not truly independent unless they can fail independently.

Q35. Are React error boundaries enough?

No.

Error boundaries catch render-time errors, but not all failures.

You also need:

textEditor
Remote loading failure handling
Chunk load error handling
Timeouts
Retry strategy
API error states
Observability
Rollback

Strong answer:

Error boundaries are necessary, but they are only one layer of failure isolation.

Q36. How do you test remote failure?

Simulate:

textEditor
remoteEntry.js 404
Chunk load failure
Remote render crash
Remote timeout
API 500
API 401/403
Malformed manifest

Verify:

textEditor
Fallback UI
Retry behavior
Navigation stability
Error logging
Alerting
Rollback readiness

12. Design System Questions

Q37. How do you keep UI consistent across micro frontends?

Use a governed design system.

It should include:

textEditor
Design tokens
Reusable components
Accessibility patterns
Documentation
Versioning policy
Visual regression tests
Contribution process

Strong answer:

Micro frontends can be independently built, but they should be consistently experienced.

Q38. What should not go into the design system?

Avoid domain-specific business components.

Bad:

textEditor
CheckoutPaymentStep
CartPromotionCalculator
ProductRankingCard
OrderCancellationPanel

Good:

textEditor
Button
Input
Modal
Toast
Card
FormField
Tabs
Skeleton

Strong answer:

The design system should contain reusable UI primitives and patterns, not domain business logic.

13. Architect-Level Questions

Q39. When would you choose micro frontends over a modular monolith?

Choose micro frontends when:

textEditor
Multiple teams own different domains.
Independent deployment is required.
Release coordination is a bottleneck.
Domains are stable.
CI/CD maturity is high.
Design system exists.
Testing and observability are ready.
Rollback is possible.

Choose modular monolith when:

textEditor
Small team
Early product
Unclear domains
No need for independent deployment
Low CI/CD maturity

Strong answer:

I would start with a modular monolith and move to micro frontends only when team scale and independent deployment justify the complexity.

Q40. When would you reject micro frontends?

Reject them when:

textEditor
One team owns the app.
Domains are unclear.
The app is small.
No independent deployment is needed.
There is no design system.
There is no platform team.
Testing/observability maturity is low.
The motivation is only “modern architecture.”

Strong answer:

Micro frontends solve organizational and deployment problems. If those problems do not exist, they may be overengineering.

Q41. How would you migrate a monolith to micro frontends?

Use a strangler pattern.

Steps:

textEditor
1. Modularize the monolith.
2. Identify domain boundaries.
3. Introduce shell app.
4. Extract one low-risk remote first.
5. Route traffic gradually.
6. Add monitoring and rollback.
7. Repeat for other domains.
8. Extract checkout/auth later, not first.

Strong answer:

I would avoid a big-bang rewrite and start with a low-risk domain like catalog, profile, or marketing.

Q42. How do you prevent the shell from becoming a new monolith?

Keep business logic out of the shell.

The shell should own:

textEditor
Routing
Layout
Auth bootstrap
Remote loading
Fallback UI
Analytics setup
Feature flags

Remotes should own:

textEditor
Domain UI
Domain state
Domain APIs
Domain behavior
Domain tests

Strong answer:

The shell should compose the product, not become the product’s business brain.

14. System Design Mock Interview

Prompt

Design a micro frontend architecture for a large e-commerce platform.

Requirements:

textEditor
Multiple teams own catalog, cart, checkout, profile, and orders.
Teams need independent deployment.
Checkout is business-critical.
SEO matters for category and product pages.
The system must support rollback and observability.

Strong Answer Structure

Start with domain split:

textEditor
Shell App
Catalog Remote
Product Details Remote
Cart Remote
Checkout Remote
Profile Remote
Orders Remote

Explain shell responsibilities:

textEditor
Top-level routing
Global layout
Auth bootstrap
Remote loader
Feature flags
Error boundaries
Analytics
Manifest loading

Explain routing:

textEditor
/categories/* → Catalog Remote
/product/:id → Product Remote
/cart → Cart Remote
/checkout/* → Checkout Remote
/profile/* → Profile Remote
/orders/* → Orders Remote

Explain deployment:

textEditor
Each remote has independent CI/CD.
Artifacts are versioned and published to CDN.
Shell loads remotes through manifest.
Critical remotes like checkout use controlled rollout.

Explain failure isolation:

textEditor
Each remote is wrapped in an error boundary.
Remote loading failures show fallback UI.
Errors include remote name/version.
Checkout failure triggers alert and rollback.

Explain performance:

textEditor
Route-level lazy loading.
Preload cart/checkout at likely points.
React singleton.
Bundle budgets per remote.
Web Vitals by route and remote.

Finish with tradeoffs:

This gives team autonomy and independent deployment, but adds complexity around routing, testing, dependency sharing, observability, and governance.

15. Rapid-Fire Questions

QuestionShort Answer
Main goal of micro frontends?Independent ownership and deployment
Best boundary?Business domain
What should shell own?Platform concerns
What should shell avoid?Domain business logic
Routing model?Shell top-level, remote nested
Communication style?Explicit contracts
Best state owner for cart?Backend + Cart Remote
React sharing?Singleton with version governance
Testing focus?Contracts + integration + E2E
Deployment model?Independent CI/CD + manifest
Rollback model?Manifest points to previous version
Failure handling?Error boundary + fallback + monitoring
Performance risk?Duplicate deps and loading waterfalls
UI consistency?Governed design system
When to reject MFEs?Small team / unclear domains / no deployment need

16. Red Flag Answers

Avoid these:

textEditor
“Micro frontends are always better than monoliths.”
textEditor
“We should split every component into a remote.”
textEditor
“The shell can store all shared business state.”
textEditor
“We do not need contract tests.”
textEditor
“If one remote fails, the user can refresh.”
textEditor
“We can load all remotes on app startup.”
textEditor
“Every remote can use any React version.”
textEditor
“Frontend permission checks are enough for security.”

These answers show shallow production understanding.

17. Strong Candidate Phrases

Use these in interviews:

textEditor
Micro frontends solve team-scaling and deployment autonomy problems, not just code-splitting problems.
textEditor
The shell should coordinate composition, not own domain business logic.
textEditor
A good remote boundary is an ownership boundary.
textEditor
Independent deployment is only safe with contracts, observability, and rollback.
textEditor
The shell owns route selection; the remote owns route interpretation.
textEditor
Unit tests prove a remote works alone; integration tests prove it works inside the product.
textEditor
Micro frontends are not truly independent unless they can fail independently.
textEditor
A modular monolith is often the better first architecture.

18. Final Revision Checklist

Before your interview, revise:

  • Definition of micro frontends
  • When to use and when to avoid
  • Shell vs remote responsibilities
  • Module Federation concepts
  • remoteEntry.js
  • Shared dependencies and React singleton
  • Routing and deep linking
  • Auth and authorization
  • Communication patterns
  • State ownership
  • Contract testing
  • E2E testing
  • Independent deployment
  • Manifest-based rollback
  • Failure isolation
  • Performance optimization
  • Design system governance
  • Migration strategy
  • E-commerce system design example

19. Summary

Micro frontend interviews are not about memorizing buzzwords.

They test whether you understand:

  • Architecture boundaries
  • Team ownership
  • Deployment independence
  • Runtime composition
  • Routing
  • Authentication
  • Communication
  • Testing
  • Performance
  • Failure isolation
  • Governance
  • Tradeoffs

The strongest final answer is:

I would use micro frontends only when team scale, domain ownership, and independent deployment justify the complexity. I would design a lightweight shell, domain-owned remotes, explicit contracts, route-level loading, shared dependency governance, contract testing, rollback, observability, and failure isolation.

That is the level expected from senior frontend and frontend architect interviews.

References

  • Micro Frontends — Martin Fowler: https://martinfowler.com/articles/micro-frontends.html
  • Micro Frontends: https://micro-frontends.org
  • webpack Module Federation Documentation: https://webpack.js.org/concepts/module-federation/
  • Module Federation Official Site: https://module-federation.io
  • AWS Prescriptive Guidance: Micro-frontends: https://docs.aws.amazon.com/prescriptive-guidance/latest/micro-frontends-aws/introduction.html
Back to Track DashboardAll Syllabus Tracks