Architecture & system design

Train

Architecture & system design

What senior frontend and fullstack design rounds actually assess, the shape of a good answer, and how the pages on the design method, component and design-system architecture, application structure, rendering and data architecture, worked designs and decision records fit together.
Nuxt rendering modesArchitecture Decision RecordsNuxt Layers

Senior interviews include a design round: "design the frontend for an e-commerce site", "how would you structure a multi-tenant dashboard", "we have a 400-component Vue app that is slow to change, what would you do". The score is not for the boxes you draw; it is for the questions you ask, the trade-offs you name, the depth you can reach on demand, and whether the plan survives contact with a team and a deadline. This section is the method and the material.

Know

  • A design answer has a shape: requirements and constraints → prioritised scope → high-level architecture (rendering per route, client/server split, data sources) → data model and API contract → component tree and state placement → one or two deep dives → cross-cutting concerns (performance, accessibility, security, i18n, observability, testing) → trade-offs, risks and evolution. Saying the shape out loud is half the score.
  • Architecture is about boundaries and ownership: who owns a style, a component, a feature folder, an API, a decision. Layers, modules, packages and services are all ways of drawing boundaries; the right one depends on team shape and change cadence, not on fashion.
  • Rendering and data are architectural decisions, made per route and per data type, with caching layers and personalisation deciding what can be shared (rendering strategies, state and data).
  • Design systems and component libraries are products with users, versions and a deprecation policy; the layers and senior craft sections cover shipping them; this section covers designing them.
  • Decisions are documented as records with context and consequences, reversible where possible, and migrations are planned as incremental strangler moves, not rewrites.
  • Trade-offs are the answer. Every choice in this section has a cost; the senior move is to name the cost you are accepting and why it is acceptable here.

How the pages fit

PageQuestion it answers
The frontend system design method"Design X in 45 minutes": the steps, the time budget, what to draw, what interviewers score
Component architecture and design systemsLayers of components, headless plus styled, props API design, versioning and governance
Application structure and boundariesFeature folders in Nuxt, enforced boundaries, monorepos, layers versus micro-frontends
Rendering and data architectureRendering per route, caching layers, BFF, realtime, auth, tenancy, i18n, edge versus region
Worked designsFour complete designs in interview shape: catalogue, dashboard, SaaS admin, upload pipeline
Decision records and trade-offsADRs, evaluating libraries, build versus buy, migrations, technical debt, saying no

How it works

The one-page design skeleton, which you can literally draw in the first minute:

1. Requirements   who / what flows / scale / devices / SEO? / a11y & i18n / offline? / compliance
2. Scope          MVP vs later; what I am NOT designing
3. Architecture   [Browser] ⇄ [CDN] ⇄ [Nuxt: routes by rendering mode | Nitro BFF] ⇄ [APIs / DB / 3rd parties]
4. Data & API     entities, endpoints or queries, pagination, realtime, cache keys
5. UI & state     routes/layouts, key components, state placement table (URL / useState / store / cache)
6. Deep dive      the hard part they care about (search, feed, checkout, upload, permissions)
7. Cross-cutting  perf budget, a11y, security, i18n, errors, observability, tests
8. Trade-offs     what I chose, what it costs, when I would change it
Gotcha· Drawing before asking

The most common failure is a confident diagram for the wrong problem. Two minutes of questions about users, scale, SEO, personalisation and constraints change the design; interviewers deliberately leave the prompt vague to see whether you ask.

Exercise

Exercise
  • Time yourself: 45 minutes, "design the frontend and API for a recipe site with user accounts and search". Record the session and check it against the skeleton.
  • For a system you know, write the state placement table and the rendering-per-route table from memory; then compare with what the code actually does.

Be able to say

Be able to say· How do you approach a system design question?

"I start with questions, because the prompt is deliberately vague: who the users are, the core flows, scale, whether search engines matter, how much is personalised, devices and accessibility and languages, offline or compliance needs, and the team and timeline. Then I scope an MVP and draw the high-level picture: the rendering mode per route, what runs on the server as a backend-for-frontend, where the data comes from. I define the data model and the API contract, then the component tree and a table of where every kind of state lives. I pick one or two hard parts to go deep on, cover performance, accessibility, security, i18n, errors and observability explicitly, and finish with the trade-offs I accepted and how the design would evolve. Naming the costs is the point; there is no free option."

Pages in this section

  1. 01The 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.
  2. 02Component 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.
  3. 03Application 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.
  4. 04Rendering 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.
  5. 05Worked 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.
  6. 06Decision 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.

Your notes

Open in Notes

Nothing yet. Notes filed here show up on every page of this section.

Deployment and operations

Nitro presets and what each implies — Node in Docker, Cloudflare Workers with bindings, Vercel and Netlify, static — plus runtime configuration and secrets, health checks and graceful shutdown, structured logging with request ids, error and performance monitoring, migrations in the release, zero-downtime deploys and rollbacks, cost, and the NuxtHub shift to self-hosting.

The frontend system design method

A 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.