If you've been following backend development, you've probably heard of microservices, the idea of splitting a monolithic backend into smaller, independent services that can be deployed and scaled on their own. Each service does one thing, owned by one team, and a failure in one doesn't bring down the whole system.

Frontend engineers looked at this and thought “why can't we do the same thing on the frontend?”

For a long time, the answer was “it's complicated”. But as web apps kept growing in scale and team size, the industry started figuring it out. Today, microfrontends are becoming a serious architecture option for large-scale frontend development.

The Problem

Unlike backends, frontends have a visual contract with the user. If you split your app into separate pieces, they still need to look and feel like one coherent product. A global theme change, a design system update, a font swap it needs to reflect everywhere at once.

On top of that, different parts of the UI often share state. The cart count in the header needs to know about the checkout flow. User session data needs to be available across the whole app.

These challenges held microfrontends back for years. But the tooling has caught up, and most of these problems now have solid, practical solutions.

The Core Idea: Shell and Remotes

The fundamental concept behind microfrontends is a shell (also called the host) and a set of remote applications.

The shell is the entry point — it's what users first hit. But it's intentionally thin. It doesn't contain actual business logic. What it does is know where to find each remote app and what each one exposes. Think of it like this for a large e-commerce platform:

Platform Team  → owns the shell (host repo)
Checkout Team  → owns the checkout feature (remote)
Profile Team   → owns the user profile feature (remote)
Catalog Team   → owns the product catalog feature (remote)
Design Team    → owns the shared design system (package)

The shell just says: when the user navigates to /checkout, load the Checkout app. The Checkout team can update their app, deploy it, even swap their framework — and the shell doesn't care. This is what makes microfrontends powerful: independent deployability.

How Do You Split Things Up?

There's no one right answer. In practice, teams usually split along three lines:

Feature/Domain — one app owns checkout, another owns the product catalog, another handles user profiles
Path-based — different URL paths map to different microfrontends (/shop → Catalog, /checkout → Checkout, /account → Profile)
Team ownership — each team owns one or more features end-to-end

These three overlap naturally. In most real setups, a team owns a feature that maps to a set of routes. The path-based split is the most common because the shell's routing config becomes the single source of truth for what app handles what.

You can also embed multiple microfrontends on a single page like a dashboard with widgets owned by different teams. More complex to pull off, but valid for certain use cases.

Monorepo vs Polyrepo

Once you've decided to go with microfrontends, the next big decision is how to organize your code. Two main approaches:

Monorepo

All your apps live in one repository. Tools like Turborepo, Nx, or pnpm/yarn workspaces manage the structure and shared dependencies.

Pros:

Shared UI and design tokens live in the same repo — no separate publishing step to keep things in sync
Easy to spot breaking changes across the whole codebase at once
New team members get the full picture immediately — one repo to clone and run
Simpler CI/CD pipeline to manage

Cons:

Everyone works in the same codebase — merge conflicts are more frequent
Repository size grows over time
Build times can increase without proper tooling (Turborepo's incremental caching helps a lot here)

Polyrepo

Each application has its own repository. The shell connects everything at runtime using Module Federation (A feature available in Vite, Webpack, and Rspack that lets you share JavaScript modules across separately deployed apps)

Pros:

Teams have full ownership of their repo — fewer conflicts, more autonomy
Each team can choose their own CI/CD, tooling, and release schedule independently
Clean separation of concerns at the infrastructure level

Cons:

More upfront setup — Module Federation config, separate CI pipelines per repo
Shared UI becomes a versioned package published to a private npm registry
Coordinating cross-app changes (like breaking API updates) takes more effort

Polyrepo is typically the choice for very large organizations where teams operate almost independently. For most other cases especially if you're just getting started with microfrontends a monorepo is the simpler and more practical option.

Solving the Shared Problems

Here's how each approach handles the three main challenges:

Shared UI components:

Monorepo — live in a packages/ui folder inside the same repo, imported directly by each app
Polyrepo — published as a versioned package to a private npm registry; each app installs and pins to a version

Shell / Host:

Monorepo — one of the apps in the repo acts as the shell and imports from sibling packages at build time
Polyrepo — the shell is its own repo; it references each remote by URL, loading the remote's remoteEntry.js at runtime via Module Federation

Shared state:

Monorepo — a shared state package in the repo, or context passed down from the shell level
Polyrepo — browser CustomEvents or a lightweight pub/sub library; apps broadcast events and subscribe to each other's updates

Quick note on the polyrepo shared state: you might see comparisons to message brokers like Kafka or RabbitMQ. The concept is the same — events broadcast to listeners — but on the frontend this all happens entirely in the browser. No actual message queues involved, it's just a pub/sub pattern using browser-native APIs.

A Simple Example (Monorepo with Turborepo)

Let's say you're building an e-commerce site. Here's what the monorepo structure might look like:

my-store/
├── apps/
│   ├── shell/          ← host app (Next.js)
│   ├── catalog/        ← product catalog (Next.js)
│   └── checkout/       ← checkout flow (React + Vite)
└── packages/
    ├── ui/             ← shared components
    └── config/         ← shared ESLint, TypeScript config

The shell handles routing and delegates to the right app:

// apps/shell/app/[...path]/page.tsx
import { CatalogApp } from '@my-store/catalog';
import { CheckoutApp } from '@my-store/checkout';

export default function Page({ params }: { params: { path: string[] } }) {
  const [section] = params.path;
  if (section === 'shop') return <CatalogApp />;
  if (section === 'checkout') return <CheckoutApp />;
}

Shared components live in packages/ui and both apps import from there:

// packages/ui/Button.tsx
export function Button({ children, onClick }: React.ButtonHTMLAttributes<HTMLButtonElement>) {
  return <button className="btn" onClick={onClick}>{children}</button>;
}

// apps/catalog/components/ProductCard.tsx
import { Button } from '@my-store/ui';

export function ProductCard({ name, price }: { name: string; price: number }) {
  return (
    <div className="card">
      <h3>{name}</h3>
      <p>${price}</p>
      <Button onClick={() => addToCart(name)}>Add to Cart</Button>
    </div>
  );
}

When the design team updates Button, all apps pick it up on the next build — no separate publish step needed. For a polyrepo setup, the structure is the same but each folder is its own Git repository, and the shell references remotes by URL at runtime via Module Federation.

Should You Use Microfrontends?

Honestly, not always. Microfrontends add real complexity, and there are cases where simpler options work just as well:

A monorepo without microfrontends — if your team is small to mid-size, a well-structured monorepo with Turborepo is usually enough
Feature flags — for gradually rolling out new features without splitting the codebase
Code splitting — Next.js and Vite handle lazy loading really well; you might not need a full microfrontend setup just for performance

Microfrontends really shine when you have multiple teams that need to deploy independently, work in parallel without stepping on each other, or when you're migrating a legacy system piece by piece to a modern stack.

That last one is one of the most underrated use cases: incremental migration. Instead of a big-bang rewrite, you wrap the legacy app in a shell and replace pages one by one with new microfrontend apps. Much less risky, and you're shipping value throughout the process instead of waiting years for a full rewrite to be done.

The Verdict: Is a Microfrontend Architecture Right for You?

Microfrontends aren't a silver bullet, but for the right team and the right scale, they are a game-changer. By decentralizing ownership and enabling independent deployments, they allow you to scale your frontend architecture without the monolithic friction. Start small, verify your contracts, and focus on delivering value one remote at a time.

Conclusion: Scaling with Micro-frontends

Micro-frontends are not a magic bullet, but they are a formidable tool for solving organizational friction. By adopting a "Shell and Remotes" mindset, you empower your teams to own their domains end-to-end without being held back by a monolithic deployment pipeline. Whether you choose a monorepo for its simplicity or a polyrepo for maximum autonomy, the key to success lies in your shared "contracts"—your design system and your state management. Don't start with a big-bang rewrite; instead, find a slice of your monolith, turn it into a remote, and start scaling with confidence.