The frontend system design method, component and application architecture, rendering and data architecture, worked designs, decision records.
Pages
- The frontend system design methodA repeatable structure for a 45–60 minute design round — clarifying requirements and non-functionals, scoping, drawing the architecture, defining data and API, placing state, going deep on one hard part, covering cross-cutting concerns and naming trade-offs — with time budgets, notation and the mistakes that lose points.
- Component architecture and design systemsLayering components from tokens to pages, headless primitives plus styled wrappers, designing props and slots APIs that scale across a team, the accessibility contract, documentation, versioning and deprecation, distribution as a package or a Nuxt layer, theming for brands, governance, and build versus adopt.
- Application structure and boundariesOrganising a large Nuxt codebase — by type versus by feature and how Nuxt's scanning constrains that, enforced dependency direction with lint rules, the shared kernel, server services versus handlers, monorepos with pnpm workspaces and Turborepo, Nuxt layers as the unit of reuse, and when micro-frontends are justified.
- Rendering and data architectureDeciding rendering per route with a criteria table, the caching layers from browser to database, server-side aggregation versus client waterfalls, realtime and auth architecture, multi-tenant theming and i18n routing, search, edge versus region placement, resilience, observability as a design input, and migration paths.
- Worked designsFour complete design-round answers in interview shape — an e-commerce catalogue and product page, a realtime analytics dashboard, a multi-tenant SaaS admin with a content site, and a file upload and processing pipeline — each with requirements, architecture, data and API, state placement, the hard part, cross-cutting concerns, trade-offs and what breaks at scale.
- Decision records and trade-offsWriting architecture decision records, running lightweight RFCs, evaluating libraries and services, build versus buy, reversible versus one-way decisions, planning migrations as strangler moves, managing technical debt with a budget, and communicating trade-offs to product and leadership.
Notes for the whole section