GUIDE · FRONTEND SYSTEM DESIGN
Frontend System Design in the AI Era, Explained
As AI gets better at writing frontend code, your way to stay relevant is **system design** and architecture.
Most system design content ignores the frontend. This is the frontend side: micro-frontends, **BFF**, **monorepos**, rendering strategies — and how AI coding changes which architectures win.
THE CONCEPTS
The mental models, one by one
- 01
Conway's Law, Two-Pizza Teams & AI
A 40-person team with a 90-minute standup isn't a process problem — it's an architecture problem. Conway's law: systems mirror the communication structure of the people building them.
The two-pizza team is becoming a one-pizza team: coding agents drive implementation time toward zero but increase verification time. Design systems that are easy to verify, not just fast to build.
The target shape: small full-stack feature teams shipping independently, plus a platform team owning shared infrastructure — all working with coding agents.
Conway's lawFeature teamsVerification time - 02
Micro-Frontends & the Shell
Backends split into microservices years ago; the frontend monolith stayed. One global CSS rule from one of fifty developers can still take the whole client down.
Micro-frontends split the client into independently deployed applications — header, product page, cart — each on its own domain, composed at runtime by a shell that owns routing, language, auth and global state.
Micro-frontendsShellIndependent deploys - 03
Vertical Slices
Combine a micro-frontend with its microservices and you get a vertical slice: one team owning a feature from pixels to database, releasing without waiting on anyone.
The career read: move toward being a vertically integrated engineer — a team of one working across the stack with a coding agent. Pure frontend-only roles are consolidating into either feature-team full-stack or platform/design-system work.
Vertical slicesFull-stack ownershipPlatform teams - 04
The API Gateway
Every client-to-service request needs the same edge functions: HTTPS, auth, caching, rate limiting, content negotiation. Implementing them per microservice is pure overhead.
An API gateway implements them once, at the front door. Behind it, services live in a private cloud and can even talk plain HTTP — fewer handshake round trips, faster internal traffic.
API gatewayEdge functionsVPC - 05
Backend For Frontend
The slowest part of shipping a frontend feature at a big company is waiting for three backend teams' backlogs.
The BFF ends the waiting: a backend owned by the frontend team that aggregates microservices into exactly the API the client needs. Desktop and mobile each get their own — different screens want different data shapes.
This is why senior frontend roles expect API design and a working grasp of GraphQL: at BFF-running companies, the frontend team is a full-stack team.
BFFGraphQLAPI designOverfetching - 06
Load Balancing
A well-optimized Node.js server handles roughly 2,000-10,000 concurrent requests. Past that, you don't buy a bigger server — you run identical instances behind a load balancer.
You'll rarely set one up by hand (cloud providers provision them in seconds), but you should be able to reason about distribution strategies — round robin, least connections — and ideally wire a small one locally with nginx and Docker Compose.
Horizontal scalingRound robinnginx - 07
Containers & Orchestration
Micro-everything creates a deployment zoo: Python services, Node services, three frontend frameworks. Docker standardizes it — a Dockerfile packages code + runtime + OS into an image that runs anywhere.
Orchestration systems like Kubernetes (or AWS ECS) run those images at scale: parallel instances, restarts on failure, load distribution. You don't need to operate them as a frontend engineer — you need to know where they sit in the architecture, because job descriptions mention them.
DockerKubernetes / ECSContainer images - 08
The CDN
Data travels at the speed of light and no faster — a transatlantic round trip costs ~200-250ms no matter how good your code is. The only fix is distance.
A CDN replicates static assets to edge locations near users. Serving from the edge is a cache hit; pushing a new version is cache invalidation — and your bundler's cache-busting hashes are how deploys stay fresh.
It remains the cheapest, fastest web-performance win: modern CDNs compress and set cache policies out of the box.
Edge locationsCache hit / invalidationCache busting - 09
Design Systems & Design Tokens
Independent teams drift: the product page button stops matching the payment button, and users can tell where one micro-frontend ends and the next begins.
A design system fixes it: design tokens (colors, borders, typography as CSS custom properties, injected by the shell) plus a package of reusable, tested, accessible components. DRY applied at the architecture level.
For AI coding this is the difference-maker: feed the design system into your agent and output stays consistent across sessions. Skip it and the UI looks vibe-coded.
Design tokensCSS custom propertiesComponent libraries - 10
Design-to-Code with MCP
The emerging workflow: designers define the system in Figma, an MCP server exposes it to your coding agent, and features get assembled straight into the vertical slices.
Know what an MCP server is and how to plug one into Claude Code or Codex. Bonus depth: Tailwind is atomic CSS — design tokens turned into atomic utility classes — and knowing that taxonomy helps you structure token systems agents can use.
MCP serversFigmaAtomic CSS / Tailwind - 11
The Monorepo
Thousands of repos means drifting code styles, dependencies and quality bars — and engineers relearning everything when they switch teams.
A monorepo puts the applications, the design system and the tooling in one place: shared lint rules, shared TypeScript config, one build system.
For AI coding it's leverage: the agent sees across service boundaries, so extracting a reusable component from a micro-frontend into the design system is one session, not a cross-repo expedition.
MonorepoShared toolingArchitectural drift - 12
MCP UI — Rendering Components from LLM Answers
Chat apps used to answer in text. MCP UI lets the LLM answer with components: product cards, maps, pickers — rendered by your frontend from instructions in the model's response.
The harness gives the LLM a tool and resource registry; the model replies with text plus render instructions; the web app parses and renders. It's the glue between traditional web UI and LLM apps.
Chat won't replace UI — it's absorbing it. Engineers who can build these hybrids stand out well past the current hype cycle.
MCP UILLM appsHybrid interfaces - 13
Core Web Vitals & the Critical Rendering Path
Three metrics quantify frontend performance: LCP (loading), INP (responsiveness to input), CLS (visual stability). They show up in job descriptions now.
They all hang off the critical rendering path: DOM, CSSOM, render tree, layout, paint, composite. Ship too much JavaScript or CSS, or fetch slowly, and LCP tanks; slow re-renders after user events tank INP.
LCP / INP / CLSCritical rendering path - 14
Code Splitting & Lazy Loading
One big bundle wrecks the vitals — every page pays for every other page's JavaScript.
Code splitting ships JavaScript where it's needed, easiest by route: the login page gets login code, the chart-heavy dashboard keeps its weight to itself. The bundler and router do the work.
The umbrella mental model is lazy loading: load on scroll, on navigation, on click — instead of everything up front.
Route-based chunksDynamic importsLazy loading - 15
Rendering Strategies: CSR, SSG, ISR, SSR
Client-side rendering gives SPAs the white screen. Static generation pre-renders at build time — perfect until content changes. ISR rebuilds only the pages that changed, triggered by your CMS.
SSR renders per-request on the server, then hydrates on the client. It's also the most complex option — teams adopt it without needing it and drown in accidental complexity. An F1 car for grocery runs.
Default to the simplest strategy your use case allows; reach for SSR only when performance or SEO is a product requirement.
CSR / SSG / ISR / SSRHydrationAccidental complexity - 16
Real-Time: Polling, WebSockets & Server-Sent Events
Three ways past request-response: polling (simple, hammers the server), WebSockets (bidirectional, heavy — right for chat between peers), and server-sent events.
AI apps are asymmetric — one query up, thousands of tokens down — which is exactly SSE's shape. Open ChatGPT's network tab and you'll find an event stream, not a WebSocket.
If you're building LLM-powered UIs, the SSE API is the one to learn.
Server-sent eventsWebSocketsPollingLLM streaming
Free Senior Training.
One session, the whole system: the fundamentals, the interview strategy, and the plan to the offer. Watch it free.
MORE GUIDES
