Three teams sharing one web application propose micro-frontends. Assess.

What the interviewer is testing

Whether you apply the same reasoning to frontend decomposition as to backend — separating logical modularity from physical distribution.

Why not micro-frontends at this scale

The motivation is organisational: a single codebase owned by many teams becomes a coordination bottleneck where the slowest team sets the cadence. That bottleneck is real at eight or ten teams. At three, coordination is usually manageable with ownership boundaries and a shared release process.

The costs arrive immediately and do not scale down:

Shared dependencies must be reconciled or duplicated — duplicating a framework across three bundles is a payload problem users feel, and users on slow devices feel it most.

Visual consistency requires design system discipline, or the product looks assembled from parts.

Cross-fragment state, routing and authentication need conventions that do not exist by default.

Debugging spans three codebases with independent release cycles.

The recommendation

A modular frontend monolith with enforced boundaries. One deployable, one bundle pipeline, and module boundaries enforced automatically — each team owns a directory, cross-module imports only through published interfaces, and an architecture test that fails the build on violation.

That gives the ownership clarity the teams want, without the runtime cost. And when a team genuinely needs independent deployment, a well-enforced module is straightforward to extract — a far better position than discovering after splitting that the boundaries were wrong.

When the answer changes

Five or more teams, genuinely independent product areas with little shared state, or a technology migration requiring two frameworks to coexist. Then server-side composition is usually the best variant, preserving both independence and good initial load.

What a strong answer adds

Asking what specifically is blocked today. If the answer is "releases are coordinated", the fix may be trunk-based development and feature flags rather than architectural decomposition — a much cheaper change that solves the stated problem.

Common weak answers

Adopting micro-frontends because the teams asked. Three separate applications, which fragments the user experience and the session.