In a runtime-integrated microfrontend setup where the host loads a remote's JavaScript bundle by a fixed URL, such as a stable remoteEntry.js path, what cache-invalidation problem can arise, and what are the common strategies to avoid serving stale code?

## Where the problem comes from The problem starts from how runtime integration necessarily works: the host doesn't have the remote's code baked into its own build, so at some point in the browser it issues an HTTP request for the remote's code, by URL. Everything downstream of that URL is subject to ordinary web-caching machinery — browser HTTP cache, any CDN edge cache in front of the origin, and sometimes intermediate proxies — none of which know anything about your deploy pipeline. If that URL is stable, the same manifest path on every deploy, which is the natural way to configure a host's remotes map so you don't have to redeploy the host every time, and it's served with a long cache header, common for JS assets because it's normally safe and great for performance, then after the checkout team deploys a new version, browsers and CDN edges that already have the old file cached will keep serving it, potentially for up to a year or until the cache entry happens to be evicted, even though the new code is live at the origin. Users experience this as 'we shipped the fix but it's not actually fixed for some users,' one of the most confusing classes of bug in a runtime-integrated system because the origin server is correct and the deploy pipeline reports success. ## Why the tension is genuine This is a genuine tension, not a bug in the tooling: long cache lifetimes on static JS assets are a core web-performance best practice, avoiding re-downloading unchanged code on every page view, but they only work correctly when combined with content-addressed URLs — the URL itself changes whenever the content changes, typically via a content hash in the filename. - **When that discipline holds**, you can cache the hashed chunk forever, safely, because a cache hit for that exact URL is guaranteed to be the exact content you want; a new deploy simply produces new hashed filenames that nobody has cached yet. - **The part of the runtime-integration setup that breaks this discipline** is the manifest or entry point itself, because by design its whole job is to be discovered at a stable, predictable URL so the host doesn't need redeploying to find it. That stable file is exactly the one piece that must not be cached long-term, or must be cache-busted on every deploy, because it's the pointer that tells the host which hashed chunk is current. ## The two-tier mitigation The standard mitigation, then, is a two-tier caching policy that matches the two-tier fetch a manifest-based setup already does: | Tier | Policy | Why | |---|---|---| | **Content-hash every actual code chunk** | serve those with aggressive, effectively-immutable caching | safe because the URL changes whenever the content does | | **The small entry or manifest file** | serve with a no-cache or very short max-age policy | so that every host page load re-checks with the origin or CDN for the latest manifest, which in turn points at the latest hashed chunks | Some teams go further and add an explicit deploy-timestamp or version query parameter to the entry URL itself so even a misconfigured CDN can't serve a genuinely stale entry file, since the URL literally changed. ## Failure modes Failure modes show up in a few characteristic ways. - **'Works for me, broken for some users'** is the most common — a support ticket says a bug is still happening after a confirmed deploy, and it turns out to be a subset of users whose browser or a specific CDN edge node still has the old manifest cached; this is hard to reproduce because it depends on cache state, not code state, and clearing your own browser cache fixes it for you but not for the affected user. - **Partial-deploy inconsistency** is another failure mode: because chunk files are content-hashed and immutable, if the manifest updates but an edge node hasn't yet propagated a newly-referenced chunk, a user can get a manifest pointing at a chunk URL that 404s for a few seconds — teams handle this with retry logic around federated dynamic imports. ## Where it shows up A well-known real pattern here: large single-page-app operators publicly describe the same content-hash-plus-short-TTL-manifest pattern for client bundle rollout, and it's the same principle runtime-integrated microfrontend setups borrow directly from general static-asset deployment practice — the microfrontend wrinkle is just that the manifest is now per-independently-deployed-team, so a stale-manifest bug can be scoped to one team's remote while the rest of the host is fine.