Micro-frontends

Micro-frontends split frontend delivery by independently owned product areas — checkout, account, catalog — each with its own deploy pipeline and team. Integration happens at runtime through module federation, iframes, web components, or a shell that composes routes. The trade-off is team autonomy versus shared UX consistency, bundle duplication, cross-app navigation, and coordinated design tokens.

Choose this pattern when organizational boundaries and release cadence differ more than technical coupling. A modular monolith with feature folders is often cheaper until multiple teams block each other on every release.

On interviews: explain when you would not split the frontend, how you handle shared auth, routing, styling, and error boundaries, and what runtime integration model you picked.

Common pitfalls: splitting by technical layer instead of business capability; duplicating dependencies and design systems; ignoring performance of loading multiple apps; treating micro-frontends as a default rather than an organizational fix.

Checklist:

• Name the ownership boundary and release independence gained.
• Describe the integration mechanism and shared shell responsibilities.
• Compare bundle size, latency, and UX consistency trade-offs.
• State rollback and versioning strategy across micro-apps.