Loading...
Loading...
Platform architecture, RADIO+OTE, migrations, and capstones for staff/principal frontend interviews.
Module 16 · Staff Frontend System Design
Staff-level frontend architecture: org-scale platform design, RADIO+OTE framework, migrations at scale, design system governance, reliability, and capstone exercises for principal/staff interviews.
Staff-level frontend architecture: org-scale platform design, RADIO+OTE framework, design system governance, migration strategies, reliability and failure modes, and full capstone walkthroughs for staff/principal interviews.
Staff frontend interviews are not harder trivia — they test judgment under ambiguity, org-scale trade-offs, and how you evolve systems over years without breaking teams.
You are expected to present multiple valid architectures, explain migration paths, define operational guardrails (SLOs, rollbacks, feature flags), and reason about team boundaries — not just pick React and draw boxes.
This module extends RADIO with Operations, Team/org constraints, and Evolution (RADIO+OTE), then walks through capstones: frontend platform for dozens of teams, real-time collaboration, and monolith-to-MFE migrations.
Prerequisite: complete Frontend System Design (RADIO basics) and Micro Frontends before this module — staff rounds assume you already know rendering, caching, and state at senior depth.
Staff frontend interviews evaluate technical strategy, not implementation speed. You must navigate ambiguous requirements, compare multiple architectures with explicit trade-offs, plan multi-year evolution, and align frontend platform decisions with org structure — the bar is judgment and influence, not knowing more hooks.
Judgment, evolution, and org-scale architecture — not bigger trivia.
At staff level, frontend system design is about technical strategy: choosing architectures that survive team growth, defining platforms other engineers build on, and planning how systems evolve over years — not just shipping the first version.
Prerequisite
Senior depth you must have before the staff bar — verify before your loop.
| Core area | Staff-level signal |
|---|---|
| Rendering | Pick CSR/SSR/SSG/ISR/RSC with cost + ops — not preference |
| State ownership | URL vs server cache vs local UI — platform contracts for shared state |
| API contracts | Cursor pagination, versioning, idempotency, cache invalidation |
| Performance | Fix order: LCP asset → blocking JS → INP long tasks → CLS |
| Security | Token storage, CSP, XSS in UGC — PII in RUM/logs |
| MFE | When NOT to — distributed monolith is worse than monolith |
What interviewers evaluate differently at each level.
| Dimension | Senior (SDE-2) | Staff |
|---|---|---|
| Scope | Single app or feature | Multi-team platform, years-long evolution |
| Ambiguity | Clarify requirements, pick one design | Frame problem, present alternatives, recommend with risks |
| Trade-offs | Explain chosen approach | Compare 2–3 options; when each wins and fails |
| Operations | Mention caching, perf budgets | SLOs, rollout strategy, rollback, incident response |
| Org | Rarely discussed | Team ownership, platform boundaries, adoption |
| Evolution | Current-state architecture | Migration path, deprecation, versioning policy |
| Depth | Correct API + component design | Cross-cutting contracts, governance, failure modes |
Extend RADIO with Operations, Team/org, and Evolution for staff answers.
Start with RADIO (Requirements → Architecture → Data → Interface → Optimizations). Staff interviewers expect three additional layers before you finish:
Operations
Team / Org
Evolution
Staff interview tip
How staff engineers drive cross-team decisions with written artifacts.
Staff impact scales through written proposals that align teams before code ships. RFCs propose change; ADRs record decisions.
| RFC Section | Purpose |
|---|---|
| 1. Summary | One paragraph — what and why in 30 seconds |
| 2. Motivation | Problem statement with data (bundle size, incident count) |
| 3. Proposed Design | Architecture diagram, API contracts, rollout plan |
| 4. Alternatives Considered | 2–3 options with explicit trade-offs |
| 5. Cross-Team Impact | Who owns what; migration burden per team |
| 6. Metrics & Success | Adoption %, perf delta, incident reduction targets |
| 7. Open Questions | What you need validated in week 1–2 |
// ADR template (Architecture Decision Record) ## Status: Accepted | Proposed | Deprecated ## Context 12 teams duplicate auth refresh logic; 3 incidents in Q2 from token races. ## Decision Shared @corp/auth-sdk in app shell; httpOnly refresh; single refresh mutex. ## Consequences + Removes ~800 LOC duplicated per team + Shell bundle +12kb gzipped - Teams must migrate by Q3; lint rule blocks legacy pattern ## Evolution Deprecate legacy refresh in Q3 via ESLint rule + codemod
Worked example
Interactive · RFC practice workspace
Draft saved locally in your browser. Practice writing before your staff loop.
Framework for platform decisions interviewers expect at staff level.
| Option | When it wins | Risks |
|---|---|---|
| Build | Core differentiator; no vendor fits; long-term ownership | Maintenance tax; team distraction from product |
| Buy (SaaS) | Commodity capability; fast time-to-value; compliance handled | Vendor lock-in; cost at scale; data residency |
| OSS | Active community; inspect source; avoid reinventing | Security patches; breaking changes; support gaps |
| Vendor | Buy when | Build when |
|---|---|---|
| LaunchDarkly | Multi-team flags, targeting, audit; compliance allows SaaS | Strict data residency; tiny flag surface |
| Datadog / Sentry RUM | Production RUM + errors at scale | Never — building telemetry is not strategic |
| Chromatic | DS visual regression across teams | Solo product with few components |
| Auth0 / Okta | Standard OIDC/SAML; SOC2 required | Internal auth platform team exists |
| Algolia | Search relevance + ops handled; fast ship | Simple SQL search; strict data isolation |
Decision rubric
Interactive — map org constraints to a recommended pattern.
Staff interviews expect you to justify architecture from constraints — not personal preference. Adjust inputs and practice explaining why the recommendation wins and when it fails.
Interactive · Architecture trade-off picker
Recommended: SSR / ISR with RSC islands
SEO-critical pages with minimal client JS on static surfaces
Alternatives
Fails when: SSR cost at scale without caching strategy
Staff architects quantify CDN, CI, RUM, and design system overhead.
| Cost center | What to model | Typical levers |
|---|---|---|
| CDN / Edge | Egress GB, request count, image transforms | AVIF/WebP, long cache on hashed assets, purge discipline |
| CI/CD | Build minutes × teams, preview env compute | Affected-only builds (Turborepo), shared cache, merge queues |
| RUM / Observability | Sessions × events, retention, custom metrics cardinality | Sample rate, low-cardinality labels, error-only replay |
| Design system | Platform FTE, Chromatic seats, Storybook hosting | Federated contributions, semver cadence, codemods vs manual |
| Third-party scripts | Tag managers, A/B tools, chat widgets | Lazy load, facade pattern, INP budget per vendor |
GDPR, PII, and SOC2 shape frontend architecture — not just legal checkboxes.
| Regulation | Frontend impact | Design response |
|---|---|---|
| GDPR | Consent, data minimization, right to erasure | Cookie banner before analytics; no PII in localStorage; delete API hooks |
| PII handling | Names, emails, IPs in logs and RUM | Hash/redact in client logs; never send PII to third-party RUM without DPA |
| SOC2 | Access control, audit trails, change management | Feature flags audited; deploy approvals; ADRs for security changes |
| CCPA / CPRA | Do-not-sell, opt-out flows | Preference center UI; honor opt-out in analytics SDK init |
Interview tip
Building what 30+ teams consume without becoming a bottleneck.
| Layer | Owned by | Staff decisions |
|---|---|---|
| Design tokens | Design system team | Semantic tokens, dark mode, density scales |
| Component library | Platform team | Versioning, breaking change policy, tree-shaking |
| App shell / routing | Platform team | Auth, nav, feature flags, error boundaries |
| Product features | Product teams | Bounded contexts, lazy-loaded remotes |
| CI/CD & budgets | Platform + SRE | Bundle size gates, Lighthouse CI, perf regression blocks |
Deep dives: Design Systems at Scale · Frontend Platform & DX
Move large systems without stopping the business.
| Pattern | When | Risk |
|---|---|---|
| Strangler fig | Replace module by module | Low — reversible per slice |
| Parallel run | Dual-write UI, compare metrics | Medium — consistency drift |
| Feature flags | Route % traffic to new stack | Low — instant rollback |
| Iframe / route proxy | Embed legacy in shell | Medium — UX, perf overhead |
| Big bang | Small app only | High — avoid at staff scale |
// Example: strangler route in app shell const routes = [ { path: "/billing/*", remote: "billing-mfe-v2" }, { path: "/legacy/*", remote: "monolith-shell" }, { path: "/*", remote: "core-shell" }, ]; if (flags.useNewCheckout && teamId in rollout.allowlist) { return <CheckoutV2 />; } return <CheckoutLegacy />;
Design for when APIs slow down, CDNs fail, and users go offline.
| Failure | User impact | Mitigation |
|---|---|---|
| API 5xx | Empty screen | Stale React Query cache + retry UI |
| CDN outage | No JS/CSS | Multi-CDN, SRI fallbacks, SW cache |
| Bad deploy | Runtime errors | Instant rollback, feature kill switch |
| Third-party script | Main thread blocked | Lazy load, sandbox iframe |
| Auth token expiry | Redirect loop | Silent refresh, httpOnly cookies |
Full module: Frontend Reliability & SLOs
Full 45-minute staff walkthrough with time budget.
Prompt: Design a frontend platform for a company with 50 product teams, shared SSO, independent deploy cadences, and LCP SLO < 2.5s p75.
| Phase | Minutes | Focus |
|---|---|---|
| Clarify requirements | 5 | Teams, deploy freq, SSO, perf SLO, regions |
| Present 2 architectures | 10 | MF remotes vs npm packages + monorepo |
| Deep-dive chosen design | 15 | Shell, manifest, DS, shared deps |
| Operations & rollout | 8 | Canary, kill switch, RUM, rollback |
| Team/org & evolution | 5 | Ownership, pilot plan, 18mo migration |
| Risks & close | 2 | Open questions, week-1 validation |
Interviewer pushback
Why not a monorepo with shared packages instead of Module Federation?
Model answer
Monorepo fits when release trains are acceptable. At 50 teams with weekly independent deploys, MF decouples blast radius. I'd pilot monorepo for platform code only (shell + DS) and MF for product remotes — hybrid is common at scale.
Interviewer pushback
How do you prevent React version drift across remotes?
Model answer
Shared dependency contract in webpack/rspack config: React and react-dom as singletons with strict semver range. CI fails if remote bundles duplicate React. Manifest service pins compatible remote versions per shell release.
Interviewer pushback
What if one remote's bad deploy breaks the shell?
Model answer
Error boundary per remote slot; shell stays interactive. Kill switch in manifest disables remote URL. RUM tags errors by remote name. Rollback is redeploy previous remote artifact only — shell unchanged.
Trade-off to articulate
Google Docs / Figma-style — 45-minute staff script.
| Phase | Minutes | Focus |
|---|---|---|
| Requirements | 5 | Users, doc size, offline?, permissions |
| Conflict model | 12 | OT vs CRDT comparison — pick one with rationale |
| Architecture | 12 | Transport, persistence, client state |
| Operations | 8 | Reconnect, split-brain, monitoring |
| Evolution & risks | 6 | Versioning ops, migration, open questions |
| Buffer | 2 | Interviewer questions |
| State layer | Sync model | Persistence | Examples |
|---|---|---|---|
| Document | CRDT/OT — merged ops | Snapshot + op log | Text, shapes, metadata |
| Presence | Ephemeral broadcast | None (in-memory) | Cursors, selections, avatars |
| Local UI | No sync | Optional local only | Toolbar, panels, zoom |
| Approach | Pros | Cons |
|---|---|---|
| OT | Mature (Google Docs); centralized ordering | Server complexity; ordering |
| CRDT | Offline/P2P friendly; no central ordering | Memory overhead; merge semantics |
| Last-write-wins | Simple | Data loss — unacceptable for docs |
| Locking | Easy | Poor UX for collaboration |
Reconnect sequence
Common pushback
Interviewer pushback
Why CRDT over OT for a design tool?
Model answer
Graphics docs have arbitrary tree structures and long offline sessions — CRDT's commutative merges avoid central sequencer bottlenecks. OT shines for linear text with a mature central server; I'd pick CRDT (Yjs) for Figma-like canvas unless OT infrastructure already exists.
Phased migration — 45-minute staff script.
| Phase | Minutes | Focus |
|---|---|---|
| Assess current state | 5 | Routes, teams, shared state leaks, deploy pain |
| MFE approach comparison | 8 | MF vs iframe vs monorepo packages |
| Migration phases | 15 | Shell extraction → pilot → scale → decommission |
| Cross-cutting concerns | 10 | CSS isolation, events, shared deps, CI |
| Org alignment | 5 | Conway's Law, team boundaries, platform ownership |
| Close | 2 | Risks, metrics, week-1 actions |
| Phase | Gate criteria to advance |
|---|---|
| 0 — Inventory | Route map + team ownership doc approved by eng leads |
| 1 — Shell live | Auth, nav, DS on shell; 100% traffic through shell proxy |
| 2 — Pilot remote | One vertical at 5% traffic; error rate within SLO for 2 weeks |
| 3 — Dependency contract | Zero duplicate React in bundle analyzer across remotes |
| 4 — CI per remote | Contract tests pass; independent deploy without shell change |
| 5 — Decommission | Monolith route traffic <1% for 30 days; runbook archived |
Interviewer pushback
Our team is only 30 engineers — should we do MFE?
Model answer
Probably not yet. MFE pays off when deploy coordination is the bottleneck — typically 50+ engineers or multiple release trains. I'd recommend modular monolith + strong DS first; revisit when merge conflicts block weekly ships.
Interviewer pushback
How do you share auth state across remotes?
Model answer
Shell owns auth context and passes session via props or a thin shared auth-sdk package (singleton). Remotes never read tokens from localStorage directly — shell injects authenticated fetch client.
Anti-pattern
Frontend stability depends on predictable backend and client contracts.
// ADR template (staff-level artifact) ## Status: Accepted ## Context: 12 teams duplicate auth refresh logic ## Decision: Shared @corp/auth-sdk in app shell ## Consequences: +12kb shell bundle; -800 LOC duplicated ## Evolution: Deprecate legacy refresh in Q3 via lint rule
How staff loops differ by company — calibrate depth and pacing.
Big tech (Meta / Google-style)
Startup
Platform-heavy org
Checklist before your staff frontend system design round.
Staff-level frontend system design interview questions.
Test your understanding — 5 questions
You are 30 minutes into a staff system design round and have drawn a clean architecture for a multi-team app shell. Which move most reliably moves you from a senior signal to a staff signal?