Client-Server Architecture

Every application you have ever used follows the same basic model. There are two parties — one that asks, and one that answers.

The Client

The client is anything that makes a request. Your browser loading a webpage. Your phone app fetching your feed. A script hitting an API. The client initiates the conversation and waits for a response.

The Server

The server is the thing on the other end. It listens for incoming requests, does the work — querying a database, running business logic, reading a file — and sends back a response.

The client never stores the data. The server does.

The Request/Response Cycle

Every interaction between a client and server follows this pattern:

1. Client sends a request — an HTTP request with a method (GET, POST, PUT, DELETE), a URL, headers, and sometimes a body
2. Server receives it, does the work
3. Server sends back a response — a status code, headers, and usually a body (JSON, HTML, an image)
4. Connection closes

This happens thousands of times per second on any production system. Every page load, every button click, every background sync — request, response, done.

Stateless by Default

HTTP is stateless. The server has no memory of you between requests. Every request arrives cold — the server doesn't know if you made a request one second ago or never.

This is a feature, not a bug. Stateless servers are easy to scale. If the server remembered nothing about you, you can route your next request to any server in the cluster and it works fine.

The tradeoff is that state has to live somewhere. Usually the client sends a token or cookie with every request so the server can identify who you are without storing session data itself.

Single Server vs Multiple Servers

Start simple — one server handles everything.

The problem is a single server is a single point of failure. It goes down, your entire application goes down. It gets overwhelmed with traffic, every user suffers.

The solution is multiple servers behind a load balancer. The load balancer sits in front, distributes incoming requests across your server pool, and routes around failures automatically.

We'll cover load balancers in depth in a future lesson. For now, understand that the jump from one server to many is one of the first scaling decisions you'll face.

Thick Client vs Thin Client

How much logic lives on the client vs the server?

Thin client — the server does most of the work. Traditional server-rendered web apps. The client just displays HTML the server sends back. Simple, but the server carries all the load.

Thick client — the client does more work. Single Page Applications (React, Next.js) fetch data from APIs and render it themselves. Faster user experience, more complex to build, puts more responsibility on the client.

Neither is universally better. Most modern applications are somewhere in between.

APIs as the Contract

The server exposes a set of endpoints — URLs that accept requests and return responses. This is the API. It's the contract between client and server.

The client doesn't care how the server works internally. It just needs to know what endpoints exist, what to send, and what to expect back. This separation is what lets frontend and backend teams work independently.

In the next lesson we'll look at the different ways APIs are designed — REST, GraphQL, and gRPC — and when to reach for each one.

Key Takeaways

• Every application is built on the client-server model
• Clients request, servers respond — HTTP is stateless by default
• State lives on the client (tokens, cookies) or in a database, not in the server's memory
• Single servers are simple but fragile — multiple servers behind a load balancer is how you scale
• The API is the contract — the client doesn't care how the server works internally