#1 Client / Server Model

What it is

The basic shape of every web app

Clients make requests, servers handle them. A load balancer in front spreads traffic across many identical servers, so one box failing doesn't take the whole app down.

Almost every design question — a chat app, a streaming platform — starts from some version of this skeleton; you layer specifics on top.

The client talks to a single address and trusts the load balancer to route; it doesn't care how many servers exist.

Core concepts

The pieces you need to know

• Client What the user runs (browser, iOS app, CLI). Knows where to send requests and how to render the response.
• Load balancer Spreads traffic across a pool of servers (AWS ALB, GCP LB); health-checks so dead boxes stop receiving traffic.
• Server Stateless compute running your business logic. Adding or removing a server should be invisible to clients.
• Backend services Databases, caches, queues, 3rd-party APIs — behind the servers, holding the data and side effects.

This layout drives where logic lives (client vs server), what to cache, how to scale, and what happens when any one piece fails.

Variants

Stateless vs stateful servers

• Stateless No memory between requests — each request carries everything (auth token, IDs, params). Any server handles any request, so you scale horizontally, redeploy safely, and survive crashes without losing sessions.
• Stateful Keeps session / in-memory data between requests — low latency, less sent per request, but the client is locked to one server and a crash loses whatever was in memory.

Default to stateless in interviews and cloud systems unless there's a specific reason (multiplayer games, persistent WebSockets, real-time collaboration).

Nuance: a stateless server can still use a database to track users — the server holds nothing between requests, the database holds the truth.

Trade-offs

What you give up

Scale and resilience aren't free.

• Stateless servers reach an external store on almost every request — an extra hop that can fail or slow down.
• The load balancer is another hop, another dependency to monitor, and another thing to pay for.
• Servers must stay interchangeable: no local files, no in-memory state, no assumptions about who you talked to last.
• Sticky sessions are a workaround, but they bring back most of the stateful pain and make scaling lopsided.

Past a handful of users the trade is obvious: eat the hops to grow without rewriting everything.

I hate stateful services, and so do most interviewers.

In an interview

What this looks like in a question

This is the starting skeleton for almost every design question — draw it first, then layer specifics. Don't spend over a minute on the base.

• Trigger “Design the backend for…” → draw client, LB, server, DB.
• Trigger “What if a server crashes?” → stateless + horizontal scaling + health checks.
• Trigger “Session data” / “multiplayer” → stateful may be justified for that one service.

State your assumption (“stateless servers behind an ALB”) and move on — the interviewer cares about what you build on top of the skeleton, not the skeleton itself.