Given that sharing a dependency as a singleton across microfrontends avoids duplicate downloads and duplicate-instance bugs, under what circumstances would an architect deliberately choose NOT to share a dependency and accept the duplication instead?

## What sharing actually trades Sharing a dependency as a singleton across microfrontends is not a free optimization -- it trades one cost for another, and a senior architect's job is to recognize when that trade isn't worth making for a particular library or team boundary. - **The benefit side** is well understood: fewer bytes downloaded (only one copy of the library ships instead of N), and for stateful libraries, correctness (avoiding duplicate-instance bugs -- broken context, desynced stores). - **The cost side** is coupling: once several independently deployed microfrontends declare a library as a shared singleton, they have implicitly entered a compatibility contract with each other. Whoever's version 'wins' at runtime becomes the version everyone else must tolerate, and a breaking change by any one team can, depending on strictness settings, either silently degrade (duplicate instance sneaks back in) or hard-break every sibling that depends on the old API. ## Why that coupling matters That coupling is precisely the kind of cross-team lockstep dependency that microfrontend architecture is usually adopted to escape in the first place -- the whole premise is that team A should be able to ship on Tuesday without asking team B's permission. ## Four reasons to accept duplication instead 1. **The cost-benefit math.** The first, most common reason to skip sharing is simply that the cost-benefit math doesn't favor it. A small, stateless utility library -- a date formatter, a validation helper, a set of pure functions with no module-level mutable state -- costs almost nothing to duplicate (a few kilobytes gzipped, sometimes less) and, because it's stateless, carries zero risk of the cross-instance bugs that make singleton sharing worth its coordination cost for something like React. Paying the coordination tax (aligning everyone's semver ranges, testing compatibility, risking a strictVersion failure on deploy) for a library that would cause no correctness problem if duplicated is a bad trade; you're buying negligible byte savings at the cost of real deployment coupling. 2. **A migration window.** A second reason is deliberate, temporary divergence during a migration. If one team is mid-migration from a major version of a framework or library to the next -- say, moving off an old state-management library while siblings are still on the current one -- forcing that library to remain a shared singleton either blocks the migrating team from starting until everyone else is ready, or blocks everyone else from their normal releases while the migration is in flight (depending on which direction the incompatibility points and how strict the version policy is). Explicitly un-sharing that dependency during the migration window lets the migrating team run their new version in isolation, duplicated, without either side blocking the other; the size cost is temporary and acceptable, and it's re-shared once the migration completes across all teams. 3. **Composition topology.** A third reason is that the 'singleton' benefit never materializes for microfrontends that are, in practice, rarely or never composed on the same page together. If microfrontend A only ever renders on one route and microfrontend B only ever renders on a completely different route, and no page composes both simultaneously, there is no actual runtime instance to deduplicate -- the browser only ever loads one of them per page view anyway. Configuring them to share a singleton in that case adds negotiation complexity and coupling risk for a benefit that never actually occurs, since they're never on the same page. This is a case where understanding the platform's actual composition topology, not just its dependency graph, should drive the sharing decision. 4. **A deliberate autonomy policy.** A fourth, more organizational reason is a deliberate autonomy policy: some platforms explicitly decide that certain libraries -- often anything outside a small, centrally governed 'platform contract' of framework/router/design-system -- are simply never shared, on principle, so that no team is ever blocked by another team's choice of library version for anything outside that contract. This trades a knowable, bounded byte cost (bounded because the org can audit and cap how many such libraries exist) for a hard guarantee of deployment independence beyond the platform contract, which is often judged worth it precisely because coordination failures are harder to detect and more expensive to unwind than a slightly larger bundle. ## The two failure modes in production - In production, **over-sharing** (sharing when you should have accepted duplication) looks like exactly what's covered under the coupling and version-negotiation questions: teams blocked on each other's release schedules, or silent duplicate-instance bugs from fallback resolution. - **Under-sharing** (duplicating when you should have shared) is the failure mode that is more mundane but still real: noticeably larger page weight from redundant framework code across several microfrontends on one page, showing up as a bundle-size regression that traces back to, say, five microfrontends each bundling their own 45KB copy of React because nobody configured the shared scope. That second one is a bug of omission rather than a deliberate trade-off, and the reason architects need a stated policy (which libraries are platform-contract singletons, which are intentionally left autonomous) rather than leaving the choice ad hoc per team.