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.
Scope Guard: What This Page Covers
This page is intentionally focused on system boundaries and rendering strategy: browser/edge/BFF/API boundaries, per-route rendering mode, and resilience guardrails. Treat it as a frontend client side architecture interview guide, not a backend topology tour.
- For entity shapes, state ownership tables, and invalidation contracts, continue with D - Data model deep dive.
- For interaction flows and UX state behavior, continue with I - Interface deep dive.
- For budgets and tuning tactics, continue with Performance optimization guide.
Client-side architecture layers
A strong frontend architecture answer separates client-side responsibilities before it talks about services. This keeps the interview grounded in UI delivery, route ownership, cache behavior, and production signals.
| Layer | Owns | Interview signal |
|---|---|---|
| View layer | Page shell, reusable components, composition boundaries | You can keep UI responsibility clear without over-splitting components. |
| Routing and rendering | Route ownership, CSR vs SSR vs SSG choice, hydration handoff | You choose a frontend rendering strategy system design by route, not by preference. |
| Data access / BFF boundary | API client, auth/session shaping, aggregation, response normalization | You avoid leaking orchestration and trust decisions into components. |
| Server-state cache | Query keys, freshness, dedupe, refetch, invalidation triggers | You control consistency, stale behavior, and race risk. |
| UI state | Modals, selected rows, focused item, drafts, optimistic flags | You keep local interaction state separate from server truth. |
| Telemetry | Web vitals, client errors, API timeout, task completion | You can prove architecture risk is measurable after launch. |
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 |
What to draw in the architecture diagram
The goal is an interview-ready frontend architecture diagram: enough boxes to explain boundaries, not enough to disappear into backend internals.
| Diagram element | Include | Why it matters |
|---|---|---|
| Browser and app shell | Shell, route container, feature modules, hydration boundary | Shows where interactive frontend work begins. |
| Route / rendering boundary | CSR, SSR, SSG, or edge rendering per key route | Makes route by route rendering strategy explicit. |
| State and cache layers | Server-state cache, URL state, UI state, persistence if needed | Prevents server truth and local interaction state from blending together. |
| API / BFF boundary | API client, BFF, downstream APIs, auth/session checks | Shows where aggregation, trust, and response shaping live. |
| Failure and observability hooks | Timeouts, partial response path, error reporting, web-vitals capture | Proves the architecture has fallback and measurement paths. |
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 |
When BFF and edge belong in the answer
A frontend system design BFF is useful only when it changes the frontend architecture, latency path, or trust boundary. Name it deliberately and explain what moves out of the client.
| Use BFF / edge when | Skip it when | Trade-off to say out loud |
|---|---|---|
| Multiple APIs must be aggregated for one screen | The page calls one stable endpoint directly | "This reduces client orchestration but adds an operational hop." |
| Auth/session shaping or permissions affect response shape | The client can safely receive the same public payload | "I am centralizing trust decisions outside reusable UI code." |
| Global latency or cacheable personalization matters | The route is auth-heavy and not cacheable | "Edge helps the read path, but observability and runtime limits get harder." |
| Partial response semantics improve the user experience | All dependencies must succeed or the flow cannot continue | "I will return usable partial data with explicit degraded UI state." |
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 |
Prompt-specific architecture decisions
Use prompt families to show that your frontend system design tradeoffs are contextual, not memorized.
| Prompt | Architecture decisions to surface | Risk to call out |
|---|---|---|
| Autocomplete / realtime search | SSR shell + CSR updates, debounced request path, query-keyed cache, BFF for ranking/personalization if needed | Stale response races and p95 suggestion latency |
| News feed | Cursor pagination, virtualized timeline, media prefetch, freshness policy, route-level cache strategy | Duplicate items, stale feed, and heavy media on low-end devices |
| Dashboard widgets | CSR dashboard, widget isolation, layout persistence, refresh schedule, permission-aware data fetch | One slow widget blocking the whole screen |
| AI chat | Streaming path, draft persistence, message ordering, reconnect behavior, optimistic/error states | Interrupted streams and duplicated messages after retry |
| Design system architecture | Package boundaries, token pipeline, component API contracts, documentation/versioning, adoption telemetry | Breaking changes across teams and inconsistent token usage |
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.
Architecture FAQ
What is frontend system design architecture?
Frontend system design architecture is the interview step where you choose client-side boundaries, rendering strategy, data flow, cache layers, BFF or API boundaries, and resilience guardrails that satisfy the requirements.
How do I choose CSR, SSR, SSG, or edge rendering?
Choose rendering per route. Use SSR or SSG for SEO and fast public entry routes, CSR for highly interactive authenticated tools, and edge rendering when global latency or cacheable personalization changes the user experience.
What should I draw in a frontend architecture interview?
Draw the browser, app shell, router and rendering boundary, server-state cache, UI state, API or BFF boundary, downstream services, failure paths, and observability hooks.
When should I use a BFF in frontend system design?
Use a BFF when it reduces client orchestration, aggregates multiple APIs, shapes auth/session-aware responses, enables partial responses, or gives a cleaner caching and latency boundary. Skip it when it is backend topology noise.
How is frontend architecture different from data model or interface design?
Architecture chooses system boundaries, rendering modes, data flow, cache layers, and resilience paths. Data model details entities and ownership, while interface design details components, interactions, accessibility, and UI states.