Micro-frontends in regulated enterprises
Building a seven-product enterprise suite with a unified design system and consistent user experience is an architecture problem before it is a product problem. When each product has its own team, its own release cycle, and its own stack preferences, the monolithic SPA that worked for the first product becomes an organisational bottleneck by the fourth.
Why we moved to micro-frontends
The decision came from two converging pressures. First, independent deployment: the HMS team should not need to coordinate with the Construction team to ship a patient portal update. Second, scale: a single React bundle importing seven product's worth of components, routes, and state management was becoming a CI nightmare and a performance liability for users on slower connections in tier-2 cities.
- Release coordination overhead was consuming 30% of engineering lead time
- Bundle size had grown to 4.2MB gzipped — unacceptable for India's network reality
- Shared state management was causing unintentional coupling between unrelated product areas
- A bug fix in the CRM module required a full regression pass across all seven products before deploying
The shell and remote architecture
We implemented Module Federation (Webpack 5) with a thin shell application responsible for: authentication state, global navigation, the design system token layer, and routing to remote applications. Each product is a federated remote that owns its own bundle, its own state, and its own deployment pipeline.
The patterns that worked
- 01Shared design system as a separate federated remote: the design system exposes components and tokens as a remote, consumed by all products. One PR to update a button style propagates to all seven products at next load — no manual dependency updates.
- 02Event bus for cross-product communication: products communicate via a lightweight pub-sub event bus on the shell, not by importing each other's modules. This keeps remotes genuinely independent.
- 03Consistent error boundary at the shell level: if a remote fails to load, the shell catches the error and shows a product-specific fallback — the rest of the suite remains operational.
- 04Feature flags at the shell: toggles that affect multiple products are managed at the shell level, not duplicated across remotes.
The anti-patterns that hurt us
- Shared global store: we initially shared a Redux store across remotes via the shell. This worked until two teams modified the same slice simultaneously, causing a state corruption bug that took 3 days to trace. We decomposed to product-owned stores with event bus integration.
- Versioning shared dependencies loosely: React 18 minor version mismatches between remotes caused subtle hydration bugs in SSR. Lock shared peer dependencies tightly and upgrade them in one coordinated PR.
- Skipping local federation dev setup: developers who tested their remote in isolation — without the shell — missed shell-dependent behaviours. We now mandate a local federation proxy as part of the dev setup script.
“The hardest part of micro-frontends is not the technology. It is agreeing on what the shell owns versus what the remote owns — and holding that boundary under deadline pressure.”
— Bizquick Platform Engineering
Compliance considerations in regulated domains
Our healthcare products (HMS, LIMS, EMR, EHR) operate under data residency and audit requirements that the frontend architecture must support. Two requirements shaped our micro-frontend approach significantly: audit log immutability and session isolation between clinical contexts.
The migration took 14 months for a team of 22 engineers. Bundle size dropped from 4.2MB to an average of 380KB per product remote. Independent deployment frequency increased from 2 releases per product per month to 12. Engineering lead time for a routine feature decreased by 40%. The investment was significant — but so is the compounding return.
