Design a Micro-frontend architecture

01Concrete scale assumptions

02Architecture decisions and rationale

03Client contracts and data boundaries

1type RemoteManifest = { name: string; version: string;2  shellContract: string; entry: string; integrity: string;3  routes: string[]; requiredCapabilities: string[] };4type ShellContext = { navigate(to: string): void; locale: string;5  emit(event: TelemetryEvent): void };

04Failure-mode analysis

05Observability and operations

• Record shell and remote versions together with load time, route transitions, errors, fallbacks, and Web Vitals.
• Maintain a live compatibility and adoption matrix across shell and remote versions.
• Use cross-boundary trace context while preserving domain ownership of detailed telemetry.
• Set per-remote JavaScript, CSS, latency, and error budgets and block a release that violates them.

06Security and accessibility boundaries

• Allow-list remote origins and manifests, enforce CSP and trusted publishing, and verify integrity where the delivery model supports it.
• Expose scoped capabilities rather than raw long-lived tokens or unrestricted shell internals.
• The composed page still needs one coherent heading, landmark, focus, announcement, and keyboard model.
• Route transitions restore predictable focus and titles; remote loading and failure states are announced accessibly.

ANSOne full answer, start to finish

Drive the discussion yourself first. This is one strong answer delivered the way you would say it in the room — a model, not the only correct design.

Start by pushing back: micro-frontends are a solution to an organizational problem, not a technical one, and they cost you a lot. Only reach for them when independent deployment by separate teams is a hard requirement. Once you have established that, the answer is about the shell, the integration contract, and not shipping React three times.

1. Step 1 · Question the premise

   Say: 'Before designing this, is independent deployment actually required? If one team can own a modular monolith, that is simpler, faster, and lighter. Micro-frontends make sense when several teams must ship on their own cadences without coordinating a release.' Assume the interviewer confirms that is the case: 'multiple teams, each must deploy independently, and they cannot all be blocked by one release train.'

2. Step 2 · Requirements

   User-facing: the product feels like one coherent app — consistent look, one navigation, one login. Hidden: each team builds, versions, and deploys its piece separately; teams communicate through a defined contract, not by reaching into each other's code; and the composed page still has one accessible structure.

3. Step 3 · The shell owns the frame

   'A shell application owns the top-level layout, the navigation, authentication, and deciding which micro-frontend mounts into which region for the current route. Each micro-frontend exposes a defined integration contract to the shell — a mount and unmount lifecycle — and is otherwise a black box to the shell.'

4. Step 4 · Boundaries follow business domains

   'The right places to split are stable business domains or route sections with clear team ownership — checkout, search, account — not small visual components that would need constant cross-team coordination. If two micro-frontends have to change together every time, the boundary is in the wrong place.'

5. Step 5 · Shared design layer and communication contract

   'All micro-frontends consume a shared design-token and component layer, so visual and accessibility consistency does not depend on every team reimplementing it. Cross-micro-frontend communication goes through an explicit, minimal, versioned contract — a small event bus or a shared state slice for genuinely cross-cutting events like a profile update — never by one team importing another team's internal store.'

6. Step 6 · Not shipping React three times

   'A shared framework like React is treated as a versioned, compatibility-tested shared dependency, enforced by dependency rules, and I would inspect the real production bundle to confirm it is not duplicated. Getting this wrong is the classic micro-frontend performance failure.'

7. Step 7 · When a remote fails

   'Each remote loads behind a timeout and an error boundary. If checkout's micro-frontend fails to load, that region shows a retry or a fallback, but the shell navigation and the rest of the page keep working. Auth tokens flow from the shell down through the defined interface, scoped, not handed out raw.'

QAInterview questions and model answers