You're advising an organization that wants to adopt runtime-integrated microfrontends, for example via Module Federation, specifically to let teams deploy independently. Under what conditions would you recommend against it, even though independent deployability sounds strictly better?

## Why the framing needs pushing back on The temptation with runtime integration is to treat 'teams can deploy independently' as an unconditional good and adopt Module Federation, or import maps, or dynamically loaded web components, as a default architecture. A principal-level answer pushes back on that framing: independent deployability is a specific tool for a specific cost, and recommending against it is often the more valuable piece of advice, because the failure mode of over-adopting it is expensive and hard to walk back once dozens of remotes exist in production. ## First: does the coordination cost exist yet? The first condition to check is whether the coordination cost you're trying to solve actually exists yet. Build-time integration's cost — shared release trains, CI queue contention, one team's broken build blocking another's ready release — only bites once you have enough independently-owned teams sharing a boundary that their release needs genuinely conflict. For a product with two or three frontend teams who mostly ship in the same sprint cadence anyway, that cost is theoretical, and Module Federation's real, immediate costs — no compile-time type safety across the boundary, shared-dependency version negotiation, a new class of runtime-only failures — are paid starting day one. I'd ask concretely: how many times in the last quarter did one team's release get meaningfully blocked or delayed by another team's build-time coupling? If the answer is rarely, the org doesn't have the problem runtime integration solves. ## Second: is the org operationally ready? Second, operational maturity has to be assessed honestly. Runtime integration doesn't remove failure modes, it relocates them from compile time, where a type error blocks a PR merge, cheap and fast to fix, to production, where a version-skew bug or a failed remote fetch surfaces as a user-facing incident, expensive and slow to diagnose. Adopting it responsibly requires: - **contract testing or generated type definitions** shared across the host/remote boundary so a breaking API change is caught somewhere before production; - **monitoring and alerting per-remote** so a broken checkout remote is detected quickly rather than discovered via user complaints; - **error boundaries and fallback UI** around every federated import so one remote's failure degrades gracefully instead of blanking a page section; - **a deliberate cache/versioning strategy** so deploys and rollbacks behave predictably. An org that hasn't built any of that yet will experience runtime integration as harder-to-debug production bugs well before it experiences the deploy-independence benefit, because the benefit shows up gradually, fewer coordination meetings, while the cost shows up immediately, a confusing incident. ## Third: how tight is the coupling? Third, coupling tightness matters more than team-org-chart independence. Two teams can be organizationally separate but functionally entangled — sharing state, frequently needing to change both sides of an API together, iterating on a shared design in lockstep. For that kind of boundary, losing compile-time type checking is a real, ongoing tax, since every cross-boundary change now needs manual coordination or a runtime contract test to catch what a type checker used to catch for free, and it's very plausible that tax outweighs the deploy-independence benefit, especially if the two teams end up needing to deploy together most of the time anyway because their changes are coupled. In that case build-time integration, possibly with strong monorepo tooling such as **Nx** or **Turborepo** affected-graph builds so unrelated changes don't block each other, plus changesets for controlled versioning, captures most of the practical speed benefit without taking on runtime's failure surface at all. ## Fourth: how latency-sensitive is the surface? Fourth, performance-sensitive or latency-critical surfaces deserve special scrutiny. Runtime-loaded remotes add real, physical network round-trips — fetch the manifest, then fetch the chunk, potentially from a different origin with its own connection setup cost — compared to a build-time bundle that's already inline in the host's first response. For something like a checkout flow or above-the-fold landing content where every extra hundred milliseconds measurably affects conversion, that cost can outweigh the organizational benefit of independent deploys, especially since techniques exist to get some of the coordination benefit, route-based code splitting, lazy-loading below-the-fold sections, inside a build-time-integrated app without paying the cross-origin runtime cost at all. ## The recommendation The concrete recommendation pattern I'd give: default to build-time integration with strong monorepo tooling; reserve runtime integration for boundaries where: - the teams are large and numerous enough that shared release trains are a measured, recurring cost; - the coupling between those specific teams is genuinely loose; - and the org is willing to invest in the contract-testing, monitoring, and cache/versioning infrastructure runtime integration requires to be safe. This mirrors publicly known trajectories — **Spotify** and **DAZN** adopted runtime-loaded microfrontends after they'd already scaled to many independent frontend teams and had documented, recurring release-train pain, not as a day-one architecture choice.