System Design Guide
architectcritical Relevance16 min read
Design Micro Frontend Retail Platform
Architecting a high-scale retail portal with runtime Module Federation, shared dependencies, and isolated error boundaries.
Architecture Focus:
Module FederationShared SingletonsError isolation
1. Problem Statement
Design a high-scale retail platform running independent checkout, feed, and catalog applications inside a unified host shell.
2. Business Context & User Friction
Retail applications scale rapidly. A crash in recommendations should not block the checkout pipeline.
3. Requirements Matrix
Functional Requirements
- Host shell loads dynamic remote modules.
- Resolve shared dependencies (React, routing libraries) at runtime.
- Enforce decoupled communications across remote applications.
Non-Functional Requirements
Performance
- Host initial load under 1.2s.
- No layout shifts during remote script loading waterfalls.
- Leighweight JS footprint.
Scalability
- Independent deployments for remote modules.
- Support millions of concurrent sessions.
Accessibility (a11y)
- Consistent accessibility labels across remote app borders.
- Manage focus states during app swaps.
Security
- Sanitize inputs passed across remotes.
- Verify sandboxed script execution.
Reliability & Failover
- React Error Boundaries isolate crashes inside remotes.
- Static placeholders on failed remotes.
Observability
- Monitor remote script download times.
- Log errors in isolated boundaries.
4. Core User Flows
Navigating retail sections
- User opens retail platform, loading HostShell.
- HostShell loads FeedRemote in background.
- User clicks Add to Cart; FeedRemote pushes event to shared bus.
- CartRemote updates item count.
5. High-Level Design & Layers
The retail platform compiles separate remotes, utilizing Module Federation to load layouts at runtime and isolating failures using Error Boundaries.
Frontend Layers
- Host Layer: HostShell container managing routes and imports.
- Remote Layer: CatalogRemote, CartRemote, CheckoutRemote apps.
- Service Layer: Global event bus communicator.
Major Components
- HostShell: Downloads remote entry manifests, mounting routing containers.
- EventBus: Decouples cross-app messages using custom event listeners.
Data Flow Pipelines
- 1. HostShell fetches remote entry manifests.
- 2. Shared dependencies resolve.
- 3. EventBus routes app events.
- 4. Error boundaries isolate failures.
6. Component Architecture & State Boundaries
| Component | Responsibility | State Owned | Dependencies |
|---|---|---|---|
| HostShellContainer | Coordinates remote mounts, active router states, and event aggregators. | Active route, basket count | HostShell, EventBus |
7. State Management
Local UI State
- Active route indicators
- Menu toggle switches
Server Query Cache State
Global/Shared State
- Active shopping cart catalog
Real-Time & Sync State
- No high-frequency real-time push state required.
8. API Contracts Design
GET/api/v1/remotes/config
Get Remote ConfigsPurpose: Download remote entry locations.
Sample Response:
{
"remotes": {
"catalog": "https://cdn/catalog.js"
}
}9. Caching Strategy
Browser/HTTP Cache
- Edge cache remote scripts files.
- Cookie store for session tokens.
Edge CDN Caching
- Edge cache static manifests configs.
Application Cache
- Cache singleton React instances in context memory.
Invalidation Policies
- Clear manifest caches on version changes.
10. System Strategies Checklist
Performance Strategy & Budgets
- Define React as singleton shared dependencies.
- Preload remote entry maps.
- Audit bundle weights.
Inclusive Accessibility Design
- Enforce uniform styles guidelines across remotes.
- Trap focus in active dialogs.
Security Safeguards & Risks
- Restrict script execution using CSP policies.
- Validate API tokens.
Telemetry & Production Observability
- Track remote loader speeds.
- Log errors in isolated boundaries.
Graceful Failure & Resilience
- Error Boundaries wrap remote imports to render placeholders.
- Fallback to static list components if dynamic remotes crash.
Deployment, Rollout & CDN topologies
- Independent deployments of remotes on CDNs.
- Host manifests deployed close to clients.
11. Architectural Decisions & Tradeoffs
Decision: Runtime Module Federation vs build-time package imports
Benefit:
Enables independent deployments and keeps host build times low.
Drawback:
Increases initial network waterfalls and testing complexity.
When To Use: When scaling portals built by multiple separate teams.
12. Interview Answer Framework
How to structure your defense of this architecture during a 45-minute technical system design session:
1. Opening Pitch
Start by explaining scaling challenges. Contrast runtime module federations with monolithic builds.
2. Requirement Clarification Queries
- Do we need support for offline shopping carts?
- Should remote updates deployment rollback dynamically?
3. Core High-Level Architecture Block
Propose a HostShell container linking dynamic remote modules and a decoupled EventBus.
4. Strategic Deep Dive Areas
- Explain Module Federation configurations.
- Detail Error Boundaries setups.
5. Summary & Defensive Tradeoffs
Conclude by evaluating testing pipelines.
13. Common Pitfalls & Extension Questions
Candidate Mistakes to Avoid
- Loading duplicate copies of React in separate remotes, bloating initial size.
- Not wrapping remote mounts in Error Boundaries, causing page crashes.
Interviewer Follow-ups / Extensions
- How would you rollback a faulty remote app deployment without re-deploying the host shell?
- How do you resolve styling conflicts when different remote apps use different CSS rules?