If You Remember One Thing
In a system design interview, Architecture is not about drawing more boxes. It is about proving that each boundary, rendering choice, and data path follows from Requirements. In the RADIO framework, this is where your frontend system design answer becomes defensible, measurable, and production-aware.
What Architecture Must Produce
Your architecture section should end with concrete artifacts, not vague claims.
| Artifact | Minimum interview bar | Why interviewer cares |
|---|---|---|
| High-level architecture diagram | Browser, CDN/edge, BFF/API, data services, observability hooks | Tests structure and boundary clarity |
| Route-by-route rendering matrix | Which routes are CSR/SSR/SSG/edge and why | Tests if trade-offs are context-driven |
| Data flow and state boundaries | Server truth vs client-derived state and sync points | Tests consistency and failure thinking |
| Caching and invalidation plan | HTTP, CDN, app cache, and invalidation triggers | Tests scale and reliability readiness |
| Risk and fallback notes | Known bottlenecks + mitigation path | Tests senior-level production judgment |
Inputs You Must Pull from Requirements
Architecture quality depends on what you carried from Requirements. This is why system design interview preparation should include a Requirements gate.
| Requirement input | Architecture decision it drives | What to say out loud |
|---|---|---|
| SEO-critical entry pages | SSR/SSG on public routes, CSR for post-login flows | "I will split rendering by route to protect crawlability and interaction speed." |
| High burst traffic | CDN caching, edge compute for read-heavy endpoints | "I am pushing cacheable work to edge/CDN to flatten origin load." |
| Strict interaction latency | BFF aggregation + request dedupe + streaming/skeleton strategy | "I will optimize the request path for p95 interaction, not just average latency." |
| A11y baseline and global audience | Architecture supports focus management, i18n bundles, graceful degradation | "Accessibility and localization are first-class architecture constraints, not polish." |
| Team ownership constraints | Modular monolith or microfrontend boundary by domain | "I am choosing boundaries by ownership and deploy risk, not trend." |
Architecture Options Matrix
| Option | When it wins | Trade-offs | Failure mode to watch |
|---|---|---|---|
| CSR-heavy SPA | Auth-gated tools, frequent interaction, low SEO pressure | Great DX and velocity; weaker first paint on slow devices | Large bundles hurt Time to Interactive |
| SSR by default | Public content with SEO + faster first contentful render | Higher server cost and cache complexity | Origin saturation during traffic spikes |
| SSG/ISR for stable content | Docs, marketing, category pages with predictable updates | Build/revalidation complexity for freshness | Stale pages if invalidation is weak |
| Hybrid per-route (recommended default) | Mixed app: SEO entry + rich dashboard interactions | More moving pieces but best fit-to-route | Inconsistent rules across teams/routes |
| Edge rendering and BFF | Global latency sensitivity + multi-API aggregation needs | Operational complexity and observability depth needed | Hard-to-debug edge/runtime mismatches |
Baseline Reference Architecture
Use this as your default starting point
User Browser
-> CDN/Edge (cache, WAF, bot/rate controls)
-> App Renderer (SSR for entry routes, CSR hydration for interactive routes)
-> BFF (auth checks, API aggregation, response shaping)
-> Domain APIs (search, profile, catalog, recommendations)
-> Data stores / cache layers
Client side:
Router + feature modules + server-state cache + UI-state store + telemetry SDK- Boundary 1: keep auth/session logic outside raw UI components.
- Boundary 2: centralize cross-domain aggregation in BFF, not in components.
- Boundary 3: separate server state cache from local UI state.
Route-by-route rendering strategy
| Route type | Rendering mode | Cache strategy | Reasoning |
|---|---|---|---|
| Home / landing / SEO pages | SSR or SSG + hydration | CDN cache with short revalidation | Protect discoverability and first content speed |
| Search results shell | SSR shell + CSR updates | CDN for shell, client cache for queries | Fast first paint + responsive filtering |
| Dashboard / account | CSR | Client cache + API cache headers | High interactivity, low SEO need |
| High-read static docs | SSG/ISR | Long CDN TTL + controlled invalidation | Cheap and globally fast delivery |
Data Flow, State Boundaries, and Caching
Server truth vs client-derived state
| State category | Owner | Example |
|---|---|---|
| Server truth | APIs + server-state cache | Product entities, permissions, pricing |
| Client view state | UI store/component state | Selected tab, modal open, sort toggle |
| URL state | Router | Search query, filters, pagination |
Cache hierarchy and invalidation rules
- CDN cache: cache public GET responses with explicit TTL and revalidation tags.
- BFF cache: short-lived aggregation cache for hot endpoints.
- Client server-state cache: dedupe requests, background refresh, stale-while-revalidate UX.
- Invalidation triggers: write mutation, permission change, deploy with schema change, manual admin purge.
Failure Modes and Resilience Design
| Failure | User-facing behavior | Architecture guardrail |
|---|---|---|
| Slow upstream API | Skeleton + partial data + stale banner | Timeout budgets + fallback response path |
| One dependency fails in aggregated response | Partial render with explicit degraded state | BFF partial response contract |
| Burst traffic event | Graceful latency increase, no white screen | CDN offload + rate limiting + circuit breaker |
| Auth refresh failure | Soft logout + preserved intent for retry | Centralized session refresh policy |
Performance and Cost Trade-offs
- Set a performance budget before optimizations (for example, p95 interaction under 150ms).
- Prioritize two biggest wins: request path reduction and JS bundle pressure.
- Call cost trade-off explicitly: aggressive SSR improves first paint but increases origin spend.
- Use progressive enhancement so low-end devices still complete core tasks reliably.
Security and Trust Boundaries
- Keep tokens out of fragile client storage patterns; use secure session strategy aligned with platform.
- Define trust boundaries at CDN, BFF, and API edges.
- Mitigate XSS/CSRF with CSP, strict output encoding, and anti-CSRF controls where needed.
- Treat rate-limiting and abuse detection as architecture components, not afterthoughts.
Observability Plan
| Signal | Metric | Alert direction |
|---|---|---|
| Frontend responsiveness | p95 interaction latency by route | Alert if sustained over budget for 15m |
| Reliability | Client-visible error rate for core flow | Alert on threshold and region skew |
| API health | BFF upstream timeout and partial-response rate | Alert on sudden slope changes |
| User outcome | Task completion rate for primary flow | Alert on statistically significant drop |
What to Say Out Loud (Architecture Script Cues)
- "I will map architecture decisions directly to the requirements we already locked."
- "I am choosing rendering per route, not globally, because route goals differ."
- "I will use BFF to reduce client orchestration and keep domain contracts stable."
- "I am separating server truth from view state to prevent sync bugs."
- "I will make failure behavior explicit: empty, error, stale, and partial states."
- "Trade-off here: this improves first paint but increases server cost and cache complexity."
- "I will define invalidation triggers now so stale behavior is predictable."
- "I am adding observability hooks so architecture risk is measurable after launch."
- "Given time, I will prioritize the highest-traffic path before secondary flows."
- "I have a clear default now; next I will detail the data model and contracts."
Architecture Timebox for Interviews
45-minute interview
| Time range | What to do | Output artifact |
|---|---|---|
| 0:00-2:00 | Confirm requirement inputs that drive architecture | Decision driver list |
| 2:00-5:00 | Draw high-level architecture and trust boundaries | System diagram |
| 5:00-7:00 | Define route rendering strategy | Route-by-route matrix |
| 7:00-9:00 | State/caching/failure model summary | Risk + fallback notes |
60-minute interview
| Time range | What to do | Output artifact |
|---|---|---|
| 0:00-3:00 | Confirm requirement drivers and trade-off priorities | Prioritized constraints list |
| 3:00-7:00 | Draw architecture and call out boundaries | Full architecture diagram |
| 7:00-10:00 | Route rendering + caching layers | Rendering and cache matrix |
| 10:00-12:00 | Resilience, observability, security recap | Hardening checklist |
Quick Drill: Typeahead Search Architecture in 7 Minutes
- Minute 0-1: Declare route strategy: SSR shell for first load, CSR for keystroke updates.
- Minute 1-2: Draw request path: Browser -> CDN -> BFF -> Search API.
- Minute 2-3: State split: server suggestions cache vs UI focus/index state.
- Minute 3-4: Add cache rules: query-keyed client cache + short CDN TTL for popular prefixes.
- Minute 4-5: Failure behavior: timeout fallback, empty state, partial stale display.
- Minute 5-6: Add observability: p95 suggestion latency, error rate, zero-result rate.
- Minute 6-7: State trade-off: simpler now with upgrade path for ranking/personalization later.
Before You Move to Data Model
- You chose rendering mode by route and explained why.
- Boundaries between browser, edge, BFF, and APIs are explicit.
- Server truth, UI state, and URL state ownership is clear.
- Cache layers and invalidation triggers are concrete.
- Failure, observability, security, and cost trade-offs are acknowledged.