Stop 19 · Frontend System DesignTopics · 11/13

Micro Frontends

In short

Micro frontends split one big web app into smaller apps owned by different teams. It's a big architectural decision, and for most projects the honest answer is "not yet".

An architecture where a large frontend app is split into independently built, deployed and owned smaller apps, composed together at runtime — used by large orgs with many teams.

The jaadu walks through a mall corridor lined with small shops, each with its own awning.

Think of it like this

A mall with separate shops

Each shop in a mall has its own owner, staff and opening hours, but they share one building, parking and signboards. Micro frontends give each team its own shop inside one website. Great for big malls, overkill for one kirana store.

Watch it happen

One app or many?

Monolith

One build and one deploy
Easy to share code and keep consistent
Teams can block each other's releases

Micro frontends

Each team deploys on its own
Needs a shell and shared design system
More setup, duplicate code risk

Start with a well-structured monolith. Split only when many teams are truly blocked.

The big ideas

What you need to know

It solves a team problem

The main win is that many teams can build and deploy their part without waiting for each other.

It has real costs

More build setups, possible duplicate libraries, harder debugging and more work to keep the UI consistent.

Split by business area

Good splits follow areas like search, checkout or account, each fully owned by one team.

Shared basics stay shared

A design system, auth and routing shell keep the pieces feeling like one product.

How it works

Should you go micro frontend?

1
Count the teams
One or two teams on one app? A well-structured monolith is usually enough.
2
Check the pain
Are teams really blocked by shared releases, not just messy code?
3
Try cheaper fixes
Feature folders, a monorepo and clear ownership often solve it.
4
Split carefully
If still needed, start with one well-bounded area, not everything at once.

Save yourself the pain

Common mistakes

Oops

Choosing micro frontends for a college project to sound impressive.

Do this instead

Explain in interviews when you would use them and why you didn't. That shows real judgement.

Oops

Splitting by technical layer, like one app for headers and one for forms.

Do this instead

Split by business area, so each team owns a full slice from UI to data.

Your mission

Make the call on paper

~20 min

Quick check

What's the strongest reason for a company to adopt micro frontends?

Go deeper

1Read a case study of a company adopting micro frontends and why.
2Learn the main composition approaches: build-time, run-time (iframe/Module Federation), server-side.
3Understand this solves an org-scaling problem — most small/medium apps don't need it.