Day 69: Deep Dive: Micro-frontend vs Monolithic SPA
Argue both sides of the micro-frontend question with concrete organizational and technical criteria, not just a stated preference.
Study
Concepts
The question is organizational scale, revisited with more nuance
Day 30 established that micro-frontends solve TEAM independence, not raw performance — this day goes deeper into the actual triggers and costs. A monolithic SPA scales well technically (one build, one bundle strategy, easy code sharing, consistent tooling) until the NUMBER OF TEAMS shipping to it grows large enough that coordination overhead (merge conflicts, shared release calendars, one team's bug blocking another's release, a single point of build failure) becomes the bottleneck, not the code itself.
A useful concrete threshold many organizations converge on: below roughly 3-4 teams working in one frontend, a well-organized monolith (with clear module boundaries, even if not physically split) is usually less overhead than micro-frontends; beyond that, the deployment-independence benefit of micro-frontends tends to outweigh the added complexity — but this is a judgment call informed by TEAM structure, not a hard rule, and should be argued from the specific organization's reality in an interview, not recited as dogma.
The costs micro-frontends do not eliminate
Splitting the codebase does not split the PRODUCT the user experiences — a consistent design system, consistent routing/navigation feel, and consistent performance budget must still be actively maintained across independently-shipped pieces, or the user-facing product visibly fragments. Shared dependency versioning (Day 30's `singleton: true` mechanism) and cross-team contracts for shared state/auth need explicit ownership — someone still has to own the "shell" and its evolving contract with each remote, which is real, ongoing organizational work, not a one-time setup cost.
A middle-ground alternative worth naming in an interview: a monorepo with a modular monolith (clear internal package boundaries, Day 42's tooling for scoped builds/tests) captures much of the "clear ownership" benefit of micro-frontends while keeping ONE deployable artifact and avoiding the runtime composition complexity — a valid, often underrated answer to "how would you structure this for a growing team".
See It
Visualizations
Visualization
Monolithic SPA vs Micro-frontends
| Monolithic SPA | Micro-frontends | |
|---|---|---|
| Deploy independence per team | No — shared release | Yes — independent deploys |
| Coordination overhead as teams grow | Increases significantly | Stays low per-team |
| Consistent UX/design system | Easier by default (one codebase) | Requires active, ongoing governance |
| Shared dependency versioning | Trivial (one package.json) | Requires singleton config + coordination |
| Best fit | 1-4 teams, or a modular monolith in a monorepo | Many independent teams, independent release cadences |
Build It
Code Examples
A modular-monolith middle ground (monorepo, one deployable)
apps/
web/ <- ONE deployable Next.js app
packages/
feature-checkout/ <- owned by Team A, clear boundary, imported by web
feature-catalog/ <- owned by Team B, clear boundary, imported by web
ui/ <- shared design system, owned by a platform team
utils/
Each package has its own owners, its own tests, and its own
Turborepo-scoped CI checks (Day 42) — but they all compile into
ONE artifact and deploy together. This gets clear ownership and
scoped CI without runtime composition complexity or dependency
version-skew risk — the right choice for many mid-sized orgs before
true micro-frontends are justified.Remember
Key Takeaways
- Micro-frontends trade deploy independence for real, ongoing coordination costs (design consistency, dependency versioning, shared contracts).
- The decision is about team count and release-cadence independence needs, not codebase size or "feels big" intuition.
- A modular monolith in a monorepo (Day 42) is a legitimate middle ground, capturing ownership clarity without runtime composition complexity.
- Someone must actively own the "shell" contract with each remote in a micro-frontend architecture — this is ongoing work, not a one-time cost.
- A strong interview answer argues FROM the specific organization's team structure and release needs, not from a general preference.
Do It
Practice
- 1Write a one-page recommendation (micro-frontends vs modular monolith) for a hypothetical 6-team, 40-engineer product org, citing specific reasons.
- 2Design the package boundaries (on paper) for a modular monolith version of a mid-sized e-commerce app with 3 feature teams.
- 3List two concrete signals from a real or hypothetical team's retros/incidents that would tip the decision toward micro-frontends.