MicroservicePatterns.com

Suggestions

  • PagePattern catalogAll patterns by category.
  • LabCircuit Breaker and Retries labCrash a dependency and tune the breaker.
  • LabSaga labFail a step and watch the compensations run.
  • PagePractice questionsScenario questions with explanations.
  • PageDesign reviewCheck your own architecture for anti-patterns.
Frontend · Core

Micro-Frontends

The Micro-Frontends pattern splits a web frontend into parts owned by different teams, usually one per business area, which are built and deployed independently and composed into one experience for the user.

Last updated

Use it when

  • Several teams work on one web application and keep blocking each other's releases.
  • Teams already own backend services by business area and need to own the screens too.

Avoid it when

  • One or two teams own the whole frontend. A well-structured single app is simpler and faster.
  • The UI is so tightly integrated that every screen needs data and state from every area.

Goes with

App ShellDecompose by Business CapabilityBackend for FrontendStrangler Fig
Test yourself

What is the Micro-Frontends pattern?

Instead of one frontend codebase shared by every team, each team owns the screens for its business area, such as search, product pages or checkout, and ships them on its own schedule. The parts are composed into one application at build time, on the server, at the edge or in the browser. A shell application usually provides the frame they run in.

What problem does the Micro-Frontends pattern solve?

Splitting the backend into services does not help much if every feature still waits for a release of one shared frontend. The frontend becomes the new monolith: one build, one pipeline, many teams queuing for it. Splitting it along the same business lines lets a team deliver a feature from the screen to the database without coordinating releases.

How do you implement the Micro-Frontends pattern?

  1. Split by business area or user journey, matching the backend services and teams, not by technical layer or widget type.
  2. Pick a composition approach: links between separately deployed pages, server or edge-side includes, or runtime loading in the browser such as module federation.
  3. Give every part the same design system and shared contracts for routing, events and the user session.
  4. Keep shared code small and versioned, and avoid shared state between parts. Communicate through URLs and a few documented browser events.
  5. Set a performance budget, so shipping several frameworks or duplicate libraries does not slow the page down.

When should you use it?

  • Several teams work on one web application and keep blocking each other's releases.
  • Teams already own backend services by business area and need to own the screens too.

When should you avoid it?

  • One or two teams own the whole frontend. A well-structured single app is simpler and faster.
  • The UI is so tightly integrated that every screen needs data and state from every area.

What do you gain?

  • Teams release their part of the UI independently
  • A feature can be owned end to end by one team
  • Parts can be rewritten or upgraded one at a time

What does it cost?

  • More moving parts, builds and deployments
  • Risk of larger downloads and slower pages
  • A consistent look and feel needs real effort

Who usually owns the Micro-Frontends pattern?

Product teams. Each product team applies this in the services, screens and data it owns. The platform may offer templates or examples, but the design decisions belong to the team. See how teams map to layers and patterns.

What are common mistakes with the Micro-Frontends pattern?

  • Each part shipping its own copy of a framework, doubling what the browser downloads.
  • Parts reaching into each other's state or DOM, recreating the coupling the split was meant to remove.
  • Splitting by component (header team, button team) instead of by business area.

Micro-Frontends in practice

Real-world example

Zalando

In 2015 Zalando set out to move away from a monolithic shop system, with many teams needing to work on the same customer-facing website.

Its Mosaic project composed pages from Fragments owned by different teams, which Zalando says was vital to that transition and let a relatively large number of teams work on the site independently. Fragments also brought differences in tech stacks, bundling and deployment, and a high entry barrier for teams, so from 2018 Zalando built Interface Framework to address them. By 2021 it served around 90% of traffic.

Source: Micro Frontends: from Fragments to Renderers, Part 1 (Zalando Engineering, 2021)

Example decision record
Context
Teams own backend services by business area, but every UI change waits for one shared frontend release.
Decision
Split the web frontend by business area into independently deployed micro-frontends, composed by a thin shell owned by a web platform team.
Consequences
  • Teams release their screens without a shared release train.
  • A performance budget and shared core libraries are needed to keep the page fast.

Test yourself on Micro-Frontends

Frontendfoundation

Six teams each own backend services for their business area, but all of them change one React codebase that ships in a single weekly release. Features finished on Monday wait for the release train. What does this point to?

3 questions involve this pattern. Practice all of them →

Done with Micro-Frontends?

Saved in this browser only. See your progress →