Compare what a rollback actually looks like — what gets reverted, how fast, and what the blast radius is — for a bug shipped via build-time microfrontend integration versus one shipped via runtime integration, such as a Module Federation remote.

## The mechanism behind the difference Rollback scope follows directly from deployment coupling, so it's worth restating the mechanism before getting to the difference. - **In build-time integration**, every microfrontend's code is compiled into one host artifact — there is exactly one thing deployed to production, and exactly one thing that can be rolled back. - **In runtime integration**, each microfrontend is deployed as its own independent artifact, a set of files behind its own URL, and the host discovers and fetches whichever version is currently live at that URL when a user's browser needs it; there are effectively N independently deployable and independently rollback-able units. ## The build-time rollback Walk the build-time rollback scenario concretely. Say a catalog microfrontend ships a bug as part of the host's Tuesday release, which also happened to include unrelated changes from checkout and account. To roll back, the platform team reverts the host to Monday's build and redeploys it. That redeploy reverts catalog's bug, but it also reverts whatever checkout and account shipped on Tuesday, even if their changes were fine — there's no way to roll back just catalog's piece of a combined artifact without either a targeted revert-and-rebuild, cherry-pick the fix, rebuild, redeploy, which is slower and itself a new deploy that needs testing, or accepting collateral rollback of unrelated, working code. The blast radius of the rollback decision is the whole host, and the speed is bounded by however long the host's full build-test-deploy pipeline takes to run again, which for many orgs is minutes to tens of minutes, sometimes longer with a large test suite. ## The runtime rollback Now the runtime scenario. Catalog is deployed as its own remote at its own URL or version, discovered by the host via a manifest or import map. If catalog ships a bug: - the catalog team can redeploy their previous known-good version to that same discovery point, or in more mature setups the platform can flip a pointer back to a previously-deployed, still-live version of catalog without even needing a fresh deploy; - and critically, checkout and account, separate deployable units the host fetches independently, are completely unaffected; they don't get touched, tested, or re-released. The rollback decision and its execution stay entirely within catalog's team, on catalog's own pipeline, often in under a minute if pointer-flip infrastructure exists, without coordinating with any other team. ## The caveat That's the theoretical win, but it comes with a real caveat: runtime integration only delivers fast, scoped rollback if the org actually built the infrastructure for it. If every remote is always deployed to the exact same URL with the previous version simply overwritten and discarded, no retained prior artifact, no versioned path, then rolling back means the catalog team has to rebuild their previous commit from source and redeploy it fresh — not meaningfully faster than a host rebuild, and now depending on catalog's own CI being fast and their prior commit being trivially reproducible. Mature runtime setups avoid this by deploying remotes to versioned, immutable paths and having the host's manifest or a routing layer simply repoint at the previous versioned path — true instant rollback with zero rebuild. ## Failure modes Failure modes on the runtime side show up as coordination gaps rather than blast-radius problems. - **Misdiagnosing the source.** Because rollback is decentralized, there's no single redeploy-the-app button, so during a live incident someone has to correctly identify which one of N independently-owned remotes is the actual source of the regression before rolling back — misdiagnosing this in a system with many remotes can waste critical incident-response time compared to a build-time system where redeploying the last good host build is always a valid first move regardless of which microfrontend caused the issue. - **The shared-dependency case.** There's also a subtler risk: because a runtime rollback only touches one remote, if the bug was actually caused by a shared-dependency version bump negotiated at the host level, rolling back just catalog doesn't fix anything — the fix has to happen at the host or shared-scope level instead, which behaves more like the build-time case. ## Where it shows up A concrete real-world pattern: platforms like **Spotify's** internal microfrontend framework and **DAZN's**, both publicly documented as moving to independently-deployed, runtime-loaded frontend modules, explicitly cite scoped, fast, single-team rollback as a primary motivation alongside independent deploy cadence — the two benefits are really the same coin, since rollback is just deploying the previous version, and it inherits whatever independence the normal deploy path has.