Microfrontends Interview Questions
With Answers & Code Examples

A microfrontend extends the microservice concept to the frontend: the UI is split into independently developed, tested, and deployed pieces, each owned by a separate team.

Problem solved:

• Coordination overhead — large teams merge into one repo; every deploy requires full-team coordination.
• Tech heterogeneity — teams can choose their framework independently (React + Vue + Angular in one app).
• Independent release cadence — checkout team deploys without waiting for recommendations team.
• Codebase scalability — bounded context prevents the monolith from becoming unmaintainable.

Integration approaches:

• Build-time: npm packages (tight coupling — shared releases needed).
• Run-time via iframes — strong isolation, poor UX.
• Run-time via JavaScript — Module Federation, Single-SPA (most common).
• Server-side composition — Edge Side Includes, server-side includes.

Module Federation (Webpack 5) lets a running application dynamically load code from another independently deployed app at runtime.

Key concepts:

• Host — the shell app that consumes remote modules.
• Remote — an app that exposes modules. It builds a remoteEntry.js file.
• Shared — dependencies both apps use (React, ReactDOM) are declared shared so only one copy loads.

// Remote webpack.config.js
plugins: [new ModuleFederationPlugin({
  name: 'checkout',
  filename: 'remoteEntry.js',
  exposes: { './CheckoutApp': './src/CheckoutApp' },
  shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
})]

// Host webpack.config.js
plugins: [new ModuleFederationPlugin({
  remotes: { checkout: 'checkout@https://checkout.example.com/remoteEntry.js' },
  shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
})]

// Host usage
const CheckoutApp = React.lazy(() => import('checkout/CheckoutApp'));

Runtime behaviour: the host downloads remoteEntry.js on demand, negotiates shared module versions, and loads only what's needed.

Microfrontends solve team scaling but introduce their own hard problems:

1. Shared dependency versioning — if host runs React 18 and a remote ships React 17, you get two React instances, breaking hooks. Module Federation's singleton: true mitigates this but requires version alignment.

2. Design consistency — each team owns their UI; without a shared design system and component library, UX fragments across the product.

3. Cross-app communication — apps can't share React state. Common patterns: Custom Events (browser), a shared event bus, or URL/query params.

4. CSS isolation — global styles bleed between apps. Fix: CSS Modules, shadow DOM, or a strict CSS-in-JS approach per team.

5. Testing — integration tests across independently deployed apps are hard. E2E tests must orchestrate multiple services.

6. Performance — multiple independent bundles, multiple network requests, risk of dependency duplication. Module Federation helps but requires careful shared config.

7. Operational overhead — N deploys, N monitoring setups, N CI pipelines. The team must be large enough to justify this cost.

Microfrontends run in separate JavaScript scopes with no shared component tree. State sharing options:

1. Custom DOM Events — the simplest approach. Fire a CustomEvent on window; other apps listen.

// App A fires
window.dispatchEvent(new CustomEvent('cart:updated', { detail: { count: 3 } }));

// App B listens
window.addEventListener('cart:updated', (e) => setCartCount(e.detail.count));

2. Shared event bus singleton — expose a pub/sub module via Module Federation's shared config. All apps import the same instance.

3. URL / query params — state that should survive navigation and deep links belongs in the URL. React Router's search params work across app boundaries.

4. Web Storage — localStorage / sessionStorage with storage events for cross-tab sync. Simple but no reactive binding.

5. Backend-for-Frontend (BFF) — the authoritative state lives server-side. Each MFE re-fetches when needed. No frontend coupling at all — preferred for complex state.

Microfrontends are an organisational solution — they only pay off when the team and product are large enough to justify the overhead.

Do NOT use microfrontends when:

• Small team (<10 engineers) — one team can't benefit from independent deployability. You just add complexity.
• Tight UX coupling — if features constantly share components and state, you're fighting the architecture every day.
• Early-stage product — domain boundaries are unclear. Split too early and you'll get the seams wrong and need to undo them.
• Performance is critical — multiple independent bundles + runtime module loading adds latency that a monolith doesn't have.
• No strong ownership model — microfrontends require each team to own and operate their slice end-to-end. Without that culture, you just get a distributed monolith.

Single-SPA is a JavaScript framework that acts as a top-level router for microfrontends. It manages application lifecycle hooks (bootstrap, mount, unmount) and decides which MFE is active based on the URL.

import { registerApplication, start } from 'single-spa';

registerApplication({
  name: '@org/checkout',
  app: () => import('@org/checkout'),
  activeWhen: ['/checkout'],
});

start();

Module Federation (Webpack 5) is a module loading mechanism — it lets one app dynamically import code from another at runtime, sharing dependencies efficiently.

Key differences:

They are often used together: Single-SPA orchestrates routing, Module Federation handles runtime code sharing.