На фоне боли разработчиков от Webpack Module Federation вспомнил как мы в Деньгах своё время организовали «настоящие» микросервисы вместо расределённого монолита микрофронтендов с хост-системой. Да, отказавшись от бесшовности и общего стейта, но с полной изоляцией каждого микросервиса и возможностью безболезненно обновлять shared-зависимости между лэйаутом и микрофронтом.

Мы разделили все бизнес-домены по принципу 1 фронт — 1 BFF. Каждый BFF не только обслуживал API как гетвей, но и занимался SSR. Отдельно мы поставили микросервис, который обозвали «сервисом обвязки» — он версионированно отдавал внешний лэйаут (шапка, меню, футер). Каждый фронтед-микросервис при рендере контроллера одновременно направлял сетевой запрос за обвязкой (по некоторым причинам там невозможно было обложиться кэшами) и финально склеивал два потока вывода (RxJS) в один общий, отправляемый в ответ браузеру.

Таким образом, каждый микросервис фронта оставался независимым, но получал общую мгновенно обновляемую обвязку и мог решать проблемы обновления либ-синглтонов через запрос обвязки нужной версии с нужной либой.

Напомню что обновление на мажор какого-нибудь реакт роутера в Webpack Module Federation обычно предлагается примерно так:
1 Подготавливаем код всех модулей
2 Подготавливаем код хост-системы
3 Полностью закрываем сервис и делаем массовый релиз всех джунглей

Я бы, наверное, предложил тут поднять новые энтри-поинты с поддержкой новой версии и перевозить на них релизнув новый хост. Но, всё равно, всё должно произойти достаточно одновременно, релизы бизнес-фич на это время придётся попридержать.

Дополнительным плюсом нашей схемы было то, что при падении сервиса обвязки мы могли просто рисовать фоллбек шапки. А вот в Module Federation падение хост-системы накроет вообще всё. Распределённый монолит он такой.