Summary
Frontend system design covers performance, state, rendering, data fetching, caching, security, accessibility, observability, and deployment.
Interview Points
- Clarify product flows, users, devices, latency expectations, and failure cases.
- Choose rendering model: CSR, SSR, SSG, streaming, or hybrid.
- Design state boundaries: server state, client state, URL state, and form state.
- Plan caching, invalidation, error handling, auth, accessibility, and analytics.
- Include observability: Core Web Vitals, JS errors, API failures, and user journeys.
2-3 Minute Interview Script
“For frontend system design, I start the same way I would with backend design: clarify requirements, scale, constraints, and user journeys. Then I choose the rendering and data model.
The big decisions are rendering strategy, state ownership, API boundaries, caching, and performance budgets. For example, a dashboard may need authenticated SSR, client-side interactivity, cache revalidation, and strong error states. A content site may prefer SSG or edge rendering.
I also separate state types: server state belongs in a data-fetching cache, URL state belongs in the route, form state belongs near the form, and global client state should be limited.
The senior-level answer includes non-functional concerns: accessibility, security, observability, release strategy, and graceful degradation. A frontend is production software, not just screens.”
Follow-Ups
- How do you decide CSR vs SSR?
- What metrics would you monitor?