System Design · Chapter 08

Microservices, all the way to the browser

You split the backend into services owned by autonomous teams — then handed the whole frontend to one central UI team, recreating the monolith you were trying to escape. Micro frontends carry the split up through the interface.

🧭

How to read this

This is a short chapter with one clean arc: a problem (your backend is split but your frontend isn't), the fix (slice the UI too and give each slice to a full-stack team), why it's worth it, and finally how the separately built pieces get stitched back into one page — on the client or on the server. Anything marked [+] is context I added; everything else is rewritten from the three teaching lessons.

The frontend quietly stayed a monolith

Micro frontends apply the microservices idea to the user interface: distinct, loosely coupled UI components, each owned end to end. It's an architectural and development approach, not a technology.

Here's the gap it closes. Microservices give backend teams full autonomy — loosely coupled services, fault isolation, and freedom to pick their own tech stack. But in a typical setup, even with microservices on the backend, the frontend is still one monolith built by a single dedicated frontend team. That central UI team becomes a coordination bottleneck and a single point of contention, undoing on the frontend the very independence microservices bought on the backend.

Figure 1 — The common setup: an independent backend of microservices, but a single monolithic frontend owned by one team. Original diagram after Illustration 1.50.

Slice vertically, own end to end

The micro frontends approach cuts the application into vertical slices — each slice runs all the way from the user interface down to the database, and one dedicated team owns the whole slice. That team includes both backend developers and the frontend developers who build the UI component for just that one service. Each team picks its own technology to build its piece; the pieces are later integrated into the complete UI.

The consequence: no central UI team. Every micro frontend team becomes a full-stack team, owning its feature from pixels to persistence.

Figure 2 — Vertical slices: each full-stack team owns a slice from UI → service → database. Dashed boundaries mark team ownership. Original diagram after Illustration 1.51.

An online game store, built from UI pieces

Micro frontends are especially popular with e-commerce. Take an online store selling video games and hardware for Xbox, Nintendo Switch, and PlayStation. Its interface is really several independent UI components, each backed by its own microservice and owned by its own full-stack team:

UI component	What it does
Search	A search bar (top center) for keyword searches, with filters for price range, console type, genre, and so on.
Game category	Shows popular and widely searched games by category on the homepage.
Add to cart & checkout	Add games to the cart and check out with address and details; may recommend related games as upsells and accept coupons/gift cards.
Payment	Offers payment options and processes the order once card details are entered.

The complete interface the user sees is all of these components rendered together.

Figure 3 — One page, four independently owned micro frontends composed into a single storefront. [+] Layout mockup illustrating the components the lesson describes.

Fragments. A team might own a large component like the whole checkout page, or a small one that slots into another page — such as the game-category block on the homepage — or both. The smaller components that embed into other pages are called fragments.

Why bother splitting the UI

Faster frontend–backend coordination

With full-stack teams owning a service end to end, there's no separate frontend team to coordinate with. Frontend and backend devs sit on the same team, so communication is quick and informal — cutting the time formerly lost to cross-team hand-offs and improving both productivity and the resulting user experience.

Freedom to pick the right technology

Because micro frontends are loosely coupled, each can use a different technology — just like microservices. Some components need only plain HTML, CSS, and JavaScript; others warrant React, Angular, or Vue. You don't have to force React on a component that doesn't need it just because another component uses it. And it works incrementally: a plain-JavaScript site can adopt React for just a new component without rewriting the whole site. Even teams on the same framework can run different versions and upgrade their libraries independently, without breaking other components.

Figure 4 — Heterogeneous frontend tech coexisting in a single UI — each component on its own framework and version. Original diagram after Illustration 1.53.

⚖️

Only for medium-to-large sites

Micro frontends are overkill for simple use cases — they'd add complexity for no gain. Using multiple technologies brings architectural and maintenance overhead: you must write extra code to combine components built with heterogeneous tech, and deal with compatibility and performance issues from mixing them. As always, trade-offs — there's no silver bullet.

Stitching the pieces: on the client

Once the individual micro frontends are built, they must be integrated into one functional website — either on the client or on the server. This mirrors the client-side vs. server-side rendering distinction from earlier in the course, and either way you must write additional logic to combine the components.

The naïve client-side approaches, and why they fall short:

Naïve approach	The problem
Unique links	Just place links so users navigate between micro frontends. But if checkout lives at `aws.amazon.com/onlinegamestore/checkout` and payment at `cloud.google.com/onlinegamestore/payment`, the browser's address visibly jumps from the AWS URL to the Google Cloud URL as the user moves — exposed to the end user.
Iframes	Embed components within a page via Iframes. But Iframes can't be bookmarked, are bad for SEO, and have stability and performance issues — a 90s way of building sites, now obsolete.

🧱

The recommended way

Use Web Components together with a framework like Single SPA — a JavaScript framework for frontend microservices that lets developers build their frontend while leveraging different JavaScript frameworks in one single-page app.

Figure 5 — Client-side integration: separately hosted micro frontends are fetched and assembled in the browser. Original diagram after Illustrations 1.54–1.55.

Stitching the pieces: on the server

With server-side integration, the server assembles the complete page and delivers it fully built to the client — rather than sending individual micro frontends for the browser to club together. Because the browser does no heavy lifting, this cuts page load time significantly. As with the client side, you write additional logic on the server to integrate the requested components.

Figure 6 — Server-side integration: the server clubs components into one pre-built page and ships it whole, so the browser just renders it. Original diagram after the lesson's server-integration description.

Tools for the job: popular frameworks include Project Mosaic, Open Components, and Podium. Server Side Includes (SSI) is a server-side scripting language for clubbing the content of multiple web pages on the server. Zalando, the European fashion e-commerce company, uses Project Mosaic to manage its micro frontends.

Recap

Micro frontends = microservices for the UILoosely coupled UI components, each owned end to end. An approach, not a technology.

Vertical slices, full-stack teamsEach slice runs UI → service → DB, owned by one team. No central frontend team.

FragmentsSmall components that embed into other pages (e.g. the homepage category block).

Two big winsFaster frontend/backend coordination, and freedom to pick (and version) tech per component.

Client integrationSkip links/Iframes (obsolete); use Web Components + Single SPA.

Server integrationServer pre-builds the whole page (Mosaic, Open Components, Podium, SSI) for faster loads.

💡

The single idea underneath it all

Autonomy is only as deep as your slices go. Splitting the backend but leaving one monolithic frontend just relocates the bottleneck to the UI team. Micro frontends extend each team's ownership all the way to the pixels — and the only real question left is where you pay to glue the pieces back together: in the browser, or on the server.