Your Frontend Does Not Need Micro Frontends. It Needs a Modular Monolith.

Walk into any frontend interview and say the words "how would you architect this," and some candidate will reach for micro frontends before they have finished breathing. It sounds ambitious. It sounds like scale. It is also, most of the time, a very expensive way to discover you did not need it.

Here is the thing the 40-second version could only hint at: micro frontends are not an architecture upgrade. They are a team scaling tool. They exist so that six teams can ship to the same product without merge-conflicting each other into a standup meeting every morning. That is the whole point. If you have one team, or two teams that share a hallway, splitting your frontend into independently deployed fragments buys you exactly nothing and charges you everything.

The price tag is not abstract. It is five repos instead of one. Five build pipelines, five sets of dependencies drifting apart, and one login page that somehow takes three seconds because each team shipped its own copy of the same UI library. Distributed systems problems, now with CSS. And debugging? Enjoy tracing a broken checkout flow across team boundaries where nobody owns the full picture. I have seen a one-person team maintain five repos. That is not architecture. That is job creation.

Now the non-obvious part, the bit interviewers actually listen for. There is a middle path that the hot-take merchants skip, because it is not flashy: the modular monolith. Same repo, one deploy, one place to debug, but with hard module boundaries enforced like you mean it. Features live in isolated modules with explicit public APIs. Nothing imports internals from a sibling module. When, and only when, the org chart demands it, those modules slide apart into separate deployments without a rewrite. You get the discipline of micro frontends with the sanity of one deploy.

So here is the decision rule. Run it before anyone says the M-word in a design review:

The Split Test: 4 questions before you touch micro frontends

1. Do you have at least 3 teams that deploy on genuinely different schedules? (No? Stop here.)
2. Can each slice of the UI be owned end-to-end by exactly one team, with no shared-state gymnastics?
3. Is your module boundary already clean enough that splitting is a deployment change, not a rewrite?
4. Have you priced the operational cost: N pipelines, N dependency sets, versioning contracts between teams?

If you answered no anywhere before question 4, start with a modular monolith. Split only when the org chart demands it.

So tell me straight: is your monolith actually modular, or just one big repo of good intentions? This is Question 3 from my Frontend System Design Interview Playbook, where the 30-second answers always sound great and the real answers take a bit more work.

Watch the 40-second version: Your Frontend Does Not Need Micro Frontends