System Design Cases
Micro-Frontends
Micro-frontends concept page demonstrating runtime composition via Module Federation. Shell host app loads independently-deployed remote MFEs (Search/Product/Checkout) from per-team CDN bundles, each with its own BFF backend and CI/CD pipeline. Shows shared design system as singleton via shared scope, cross-MFE communication through window CustomEvents bus, and React error boundaries for failure isolation. Four scenarios: initial load with Module Federation runtime, independent deploy by Checkout team without redeploying others, cross-MFE event from Search to Checkout via event bus, and failure isolation when one MFE bundle fails to load. Includes ADR on when MFE worth the complexity (Spotify/IKEA/Zalando scale: 100+ engineers, 5+ teams) vs anti-pattern for small teams.
Micro-frontends: independent delivery with explicit runtime contracts
Micro-frontends разделяют frontend по business/ownership boundaries и позволяют отдельным builds выпускаться независимо. Эта независимость условна: shell, route contract, shared dependencies, design tokens, telemetry и browser security policy остаются общими интеграционными поверхностями.
Module Federation загружает remote module асинхронно и затем выполняет его в общем JavaScript realm. Это композиция, не security sandbox: скомпрометированный remote обычно получает те же DOM и origin privileges, что host.
Проверяемые утверждения
- Независимый deploy требует versioned compatibility contract и rollback target; runtime loading без pinning превращает каждый refresh в неявный release.
- Shared dependency negotiation уменьшает duplication, но не доказывает semantic compatibility. Singleton может скрыть несовместимый API до runtime.
- CSP, trusted origins, immutable artifacts и SRI/integrity metadata уменьшают supply-chain risk, но динамический loader обязан действительно enforce выбранную политику.
- Iframe даёт более сильную isolation boundary, но добавляет cross-context messaging, focus, responsive layout и accessibility trade-offs.
Границы и компоненты
| Компонент | Роль в модели |
|---|---|
| Browser | load shell |
| Versioned Host Shell | load shell; resolve pinned versions; load checkout module; load account module; release and error context; route containment |
| Signed Release Manifest | resolve pinned versions |
| Checkout Remote | load checkout module; consume compatible contract |
| Account Remote | load account module; consume compatible contract |
| Shared Contracts and Design Tokens | consume compatible contract; consume compatible contract |
| Cross-build Observability | release and error context |
| Route Fallback and Rollback | route containment |
Сценарии
Compose pinned compatible remotes
The shell reads an environment-specific release manifest, verifies allowed origin/integrity metadata and loads exact checkout and account versions compatible with its contract range.
Проверяемый исход: A user session is reproducible from shell and remote release IDs; refresh does not silently select an unreviewed latest build.
Contain a remote load failure
Checkout fails integrity, timeout or initialization checks. The shell records the release context and mounts a tested route fallback without corrupting account navigation.
Проверяемый исход: Failure stays inside an explicit boundary, the user receives an accessible recovery action, and rollback remains selectable.
Evolve a shared contract compatibly
A design-system or routing contract adds an optional capability. Consumers pass contract tests before the shell raises its minimum supported version and later removes the old path.
Проверяемый исход: Producer and consumer deploy order is safe, and shared-library deduplication is separate from API compatibility.
Secure the remote delivery path
The shell accepts modules only from an allowlisted origin and immutable path with enforced integrity/CSP policy. A mutable or unexpected artifact is rejected before evaluation.
Проверяемый исход: Supply-chain controls fail closed and telemetry identifies the manifest, URL and policy result without executing untrusted code.
Failure, concurrency и evolution checklist
- Put error, loading and timeout boundaries around each independently loaded route; test failure before and after module evaluation.
- Keep a last-known-compatible release set and make rollback change the manifest atomically. Rolling back only the host can preserve an incompatible remote.
- Avoid distributed global mutable state and undocumented DOM events. Version cross-build messages and ownership explicitly.
- Test navigation, focus restoration, analytics correlation and CSS isolation across mixed-version canaries.
Security и privacy
- Treat an in-process remote as same-authority code, not tenant isolation. Use a stronger boundary such as sandboxed cross-origin iframe when the trust model requires it.
- Allowlist artifact origins, use TLS, immutable version paths, CSP and enforced integrity where the loader/browser path supports it.
- Do not place authorization decisions in remote UI. APIs authorize subject, tenant and object regardless of which frontend bundle issued the call.
- Minimize shared credentials and globals; a compromised remote can otherwise exfiltrate any data readable in the common realm.
Метрики, формулы и допущения
initial_transfer = host_bytes + Σ critical_remote_bytes + shared_bytes_not_deduplicated; compare compressed transfer and parse/execute CPU separately.release_combinations = Π supported_versions_iis an upper bound if every remote can vary independently; pinning tested sets deliberately collapses this state space.remote_error_rate = failed_mounts / attempted_mountsmust be segmented by host version, remote version, route and browser.- A route performance budget should include added requests, critical-path depth and main-thread work; independent deployment does not make these costs independent.
Числа и bounds выше действуют только при названных units, population и assumptions. Ни паттерн, ни browser API сами по себе не задают SLA, capacity или correctness.
Решения для production review
- Split by durable product/team boundary, not by arbitrary visual component size.
- Choose build-time, server-side, runtime module or iframe composition from release and trust requirements; none is universally superior.
- Define host ownership of routing, authentication context, design-system baseline, accessibility shell and observability before allowing independent releases.
Первичные и официальные источники
- https://webpack.js.org/concepts/module-federation/
- https://html.spec.whatwg.org/multipage/webappapis.html#import-maps
- https://www.w3.org/TR/CSP3/
- https://www.w3.org/TR/SRI/
Scope note
Диаграмма использует Module Federation как один runtime example. Она не утверждает, что micro-frontends требуют webpack, что shared singleton безопасен или что независимый repository автоматически даёт независимый deploy.