I think it's less about the technology than the organizational structure. If you have more than one monolith (aka any company with an acquisition) you either ha

I think it's less about the technology than the organizational structure. If you have more than one monolith (aka any company with an acquisition) you either have to have it in code in two places (gross) or as a library. If you have it as a library, then you have N version bumps to do an N pipelines to deploy. Not hard technically, but tons of overhead. This means that you lose independence and doing A/B testing becomes very difficult when you can't really control what the user is seeing because the version is pinned. A micro front end allows you to deploy independently, test independently, and truly own your code. Network hops are reasonably cheap for most consumer applications and collaboration on a shared component is very expensive. I'm speaking from the perspective of a checkout flow, which my company is actively ripping out from the monolith in order to ensure people outside the monolith can use it AND to ensure we're able to do the price testing/conversion rate testing at a level that doesn't need a separate suite of tools for each business unit. This also has the benefit of reducing integration points with the billing system leading to better standardization and consolidated data in one billing system.