Client-Server Architecture

Before microservices, before serverless, before any of the architectural patterns you'll read about in this course, there was one fundamental idea that everything else builds on: client-server architecture.

It's so basic that it's easy to overlook. Not understanding it deeply makes every other system design decision shakier. Let's get it exactly right.

The Core Idea

Client-server architecture splits a system into two roles:

• Client: the thing that makes requests
• Server: the thing that handles requests and sends back responses

That's it. The client wants something. The server has it (or can compute it). The client asks. The server answers.

What makes this powerful is the separation of concerns. The client doesn't need to know how the server stores data. The server doesn't need to know what the client does with the response. Each side can change independently as long as they agree on the protocol — the language they use to communicate.

Who's the Client?

"Client" doesn't mean "browser." A client is any process that initiates a request:

• Web browsers (Chrome, Safari) — the most familiar client. Sends HTTP requests, renders HTML/CSS/JS.
• Mobile apps (iOS, Android) — send HTTP/REST or GraphQL requests to backend APIs.
• CLIs — git push, curl, aws s3 cp — all clients making requests to remote servers.
• Other servers — in a microservices system, your Order Service is a client to your Inventory Service. Clients and servers are roles, not types of machines.
• IoT devices — a smart thermostat sending temperature readings to a cloud backend is a client.

The defining characteristic: the client initiates the communication. It sends a request and waits for a response.

Who's the Server?

A server is any process that listens for requests and responds to them. Servers can be:

• Web servers (Nginx, Apache) — serve static files and proxy requests
• Application servers — run your business logic (Node.js, Django, Spring Boot)
• Database servers — your app server is a client to Postgres or MySQL
• Cache servers — Redis, Memcached
• Message brokers — your app publishes to Kafka (client), Kafka stores and forwards (server)

Servers are typically designed to handle many clients simultaneously. That concurrency is what makes them interesting to design.

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

algobase.dev

The standard 3-tier architecture. The browser sends HTTP requests to the app server, which runs business logic and queries the database. Clients never talk to the database directly.

1 / 10.5×1×2×3×Playground

A browser sends HTTP requests to an app server, which queries the database. The app server handles business logic so clients never touch the database directly.

The Request-Response Cycle

In HTTP (the protocol that runs the web), every interaction follows the same cycle:

1. Client sends a request — HTTP verb (GET, POST, PUT, DELETE), URL, headers, optional body
2. Server processes the request — validates input, reads/writes data, applies business logic
3. Server sends a response — status code (200, 404, 500), headers, optional body
4. Client handles the response — renders UI, updates state, handles errors

The connection is (typically) short-lived. HTTP/1.1 reuses connections via keep-alive. HTTP/2 multiplexes multiple requests over one connection. But the fundamental model is the same: discrete request-response pairs.

This synchronous, stateless request-response model is the default. WebSockets, SSE for server push, and long polling are all workarounds for cases where pure request-response isn't enough.

Stateless Servers: The Key Design Principle

Well-designed servers are stateless. Each request contains all the information needed to process it. The server doesn't remember anything between requests.

This is crucial for scalability. If the server is stateless, you can put any number of servers behind a load balancer and route requests to any of them. Add more servers when traffic grows. Remove them when it drops.

If the server is stateful — if it remembers session data in memory — you have to route every request from a given user to the same server (sticky sessions). Now adding and removing servers becomes much harder.

The workaround: move state to a shared external store. Sessions go in Redis. User data goes in Postgres. The application server stays stateless and becomes trivially scalable.

Tiers: 1-Tier, 2-Tier, 3-Tier, N-Tier

"Architecture tiers" describe how many distinct layers of processing sit between the user and the data.

1-Tier Architecture

The client, server, and database all run on the same machine. Your local dev environment when you run npm run dev is 1-tier. So is a classic desktop app that writes to a local SQLite database. Simple, but doesn't scale and can't be shared across users easily.

2-Tier Architecture

The client communicates directly with the database server. Think of a desktop accounting app that connects directly to a shared SQL Server over a LAN. Faster to build, but the client has to contain business logic, and you're exposing the database to clients. This creates security and maintenance problems.

3-Tier Architecture

The standard modern web architecture:

1. Presentation tier — browser/mobile app (client)
2. Application tier — your API server (handles business logic)
3. Data tier — database server

The application server sits between the client and the database, enforcing business rules and access control. This is what 99% of web apps use. The layers can scale independently: add more app servers without touching the database, or migrate to a different database without changing the clients.

N-Tier Architecture

Add more layers: caching layer between app and DB, CDN in front of the web tier, separate microservices for auth, payments, notifications. Each layer has a specific job. This is what large-scale systems look like in practice.

What This Means for System Design

When you're designing a system, the client-server model immediately raises the right questions:

• Who initiates communication? (defines what's the client and what's the server)
• What protocol do they use? (HTTP, WebSocket, gRPC, AMQP)
• Is the server stateless? (determines horizontal scalability)
• How many tiers do you need? (separates concerns, enables independent scaling)
• Where does state live? (almost always in a data tier, not in the application tier)

Summary

Client-server architecture is the foundational model for virtually every networked system. Clients initiate requests; servers handle them and respond. The key to scalable server design is statelessness: if each request is self-contained, you can run as many server instances as you need behind a load balancer. The 3-tier model (client → application server → database) is the standard for web applications because it separates concerns, enforces business logic at the server level, and allows each tier to scale independently. Everything else in system design, including load balancers, caches, message queues, and microservices, is built on top of this foundation.