Frontend vs. Backend System Design
How frontend system design differs from the backend interviews you've heard about.
When people say “system design,” they usually mean the backend kind — servers, databases, scaling. Frontend system design is newer, but increasingly expected. The good news: it's the same framework (RADIO). What changes is the concerns inside each step.
Same framework, different components
RADIO applies to both frontend and backend system design — the steps (requirements, architecture, data, interface, optimizations) are the same. What differs is the components and concerns that show up inside each step. Backend focuses on the server side; frontend focuses on the client side.
Servers, APIs, load balancers, caches, microservices, message queues. The work centers on the server side: database schema, capacity estimation, throughput, scaling, and sharding (e.g. storing a celebrity's posts differently from a normal user's).
Whose concern is it?
The fastest way to feel the split is to sort real concerns. Some are clearly one side, some are genuinely shared. Tap a bucket for each:
One problem, two lenses
Take a classic prompt — design the Facebook news feed. The same problem pulls each side toward completely different questions. Switch the lens:
- How should the database schema and feed generation work?
- Capacity estimation and expected load on the servers.
- How do services scale as the feed grows?
- Do we store posts from a user with 100k followers differently from a normal user?
Understand the other side
Nobody builds in isolation. The more you understand the other side, the better your own decisions get — you don't need to know how the backend implements caching, just enough to reason with the engineer who does. That shared minimum lets you both weigh options and land on the right call together.
Local maximum vs. global maximum
There's a useful idea from The Staff Engineer's Path: a local maximum optimizes for your scope; a global maximum optimizes for the whole system. The best frontend-only solution isn't always the best overall solution. Flip the lens and watch which option wins:
Convenient for your team right now
Best for the whole org
The same trap shows up in API shapes: an endpoint that's convenient for your screen may not be reusable for iOS or Android, or scalable on the server. The best call optimizes the whole system — frontend and backend together.
Check your understanding
Trace a contract
Pick one API your frontend calls. Write down what the frontend needs from it (shape, latency, pagination) and what the backend cares about (scalability, reuse across platforms). Where do those pull in different directions — and what would the global-maximum contract look like?
- →RADIO is shared; frontend and backend differ in the concerns inside each step.
- →Backend leans server-side (scaling, sharding, schema); frontend leans client-side (rendering, state, a11y, pagination).
- →The two meet at the interface — a contract both sides own.
- →Optimize for the global maximum (whole system), not just your local scope.