22 Micro-frontend interview questions with detailed answers, sorted from basic to advanced. Free to practice, with progress saved automatically.
Micro-frontend is an architecture that splits a frontend application into independent parts, built and deployed by separate teams and composed into one product. The questions here lean toward experience applying it in real projects, such as describing how an organisation uses it, which calls for explaining why it was chosen, how the parts are composed, and what trade-offs followed.
This is an experience question: the interviewer wants to know whether you have actually done it or only read the theory. Micro-frontend means splitting a large frontend into parts that independent teams build and deploy, then composing them into one page. Answer from real experience,…
A micro-frontend setup splits one product's UI into several small frontend apps, each owned end to end by one team from code to deploy, and composes them into a single page for the user. It is the microservices idea applied to the frontend. Example: an…
A monolith frontend is one codebase, one build and one deploy for the whole UI. A micro-frontend setup splits the UI into several small apps, each owned and deployed separately by one team. Monolith frontend Micro-frontend --------- Codebase One repo for the whole UI Several…
There are two groups, which differ in when the micro-frontends are assembled into the container app (the shell that holds the header, routing, and loads the pieces). Build-time: each micro-frontend is published as an npm package, and the container installs it like a library and…
Module Federation is a Webpack 5 feature that lets one app (the host) load code from another app (a remote) at runtime, with a mechanism for sharing dependencies. It is the most common foundation for building micro-frontends today. A remote declares the modules it lends…
single-spa is an orchestrator framework for micro-frontends: it decides which micro-frontends are shown for the current URL and calls their lifecycle functions to attach them to or remove them from the page. It solves running several independent apps, even ones written in different frameworks (React,…
The principle is loose coupling: micro-frontends never call into each other's code; they only exchange data through a small, explicit contract (event names, data shape). That way each team can change and deploy its piece without breaking the others. The product piece does not know…
Common model: split routing into two levels. - The shell/container owns top-level routing: it decides which path activates which micro-frontend. For example, the shell maps /checkout/ to the Checkout app. single-spa does this via activeWhen. - Each micro-frontend manages its own sub-routes internally: inside Checkout…
CSS is global by default: a selector like .title in micro-frontend A applies to every element with that class on the page, including those inside micro-frontend B. Since pieces are written and deployed by different teams, a class name collision is only a matter of…
Micro-frontends trade per-team autonomy (each team picks its tech and deploys its own piece) for a set of technical and operational costs. Four downsides come up most often: - Larger payloads: each piece is built separately, so it easily ships its own copy of a…
An iframe embeds a whole separate HTML page inside the page, with its own document, CSS and JavaScript. Using it for micro-frontends means each piece is an independent page, and the shell just places an <iframe src pointing at it. Just to make the iframe…
Each micro-frontend is packaged as a custom element, a self-defined HTML tag such as <team-cart. The shell just puts that tag on the page without knowing whether it is written in React, Vue or Angular. The HTML tag becomes the shared interface between frameworks. What…
They solve two different, complementary problems — they are not mutually exclusive. Module Federation handles LOADING and SHARING code at runtime (via webpack/rspack) — the host pulls modules from a remote and shares dependencies. single-spa handles ORCHESTRATION and app LIFECYCLE — registering micro-frontends, deciding which…
Micro-frontends are tested in layers: each piece tests itself like a normal app, and what you add is coverage for where the pieces connect. That is where bugs show up: the Cart team renames a field in an event, the Header team still reads the…
In short: you trade "organizational speed" for "technical complexity". Pros: - Team autonomy: each team owns a piece end-to-end. - Independent deployment: release without waiting on others. - Scaling with the number of teams: many teams work on one product without stepping on each other.…
There are two groups: integration libraries (which stitch apps together) and platform techniques from the browser or the server. Integration libraries: - Module Federation (Webpack 5, with ports for Rspack and Vite): one app loads another app's code at run time and shares dependencies like…
