system-design · beginner

Client–Server Architecture — Request Work From a Shared Machine

Start here

Client–server architecture is a way of organizing software into two roles:

A client — the program the user touches (browser, mobile app, desktop app, or even another service).
A server — a program that waits for requests, does work, and sends responses.

The client says “please do X.” The server decides whether X is allowed, does the work (or asks a database), and answers.

You should care because almost every internet product you use is client–server: banking apps, email, Learning Lab itself. Later ideas—APIs, load balancers, microservices—are refinements of this basic split.

What you will learn

Define client and server without jargon.
See why the split exists (shared data, security, updates).
Walk a request from button click to database and back.
Contrast with peer-to-peer and pure local apps.
Work a complete notes-app example.
Know failure modes: server down, slow network, chatty clients.
Connect this pattern to APIs and multi-server farms.

What you should know first

Topic	Why
System Design Foundations	Overall map of backend pieces
Everyday web use	You already use clients and servers daily

Words you need before we begin

Term	Plain English
Client	Program that initiates requests on behalf of a user or another system.
Server	Program that listens for requests and provides services.
Request / response	The message pair: “please…” and “here is the result / error.”
API	Application Programming Interface — the agreed rules for those messages.
Stateless server (common goal)	Server does not need to remember prior requests in its own memory to handle the next one; state lives in databases/tokens.
Backend	Server-side systems users do not run on their phones.
Frontend	Client-side UI code.
Round trip	One request to the server and its response back.

Simple story: restaurant table service

You (the client) sit at a table and order. Kitchen staff (the server) cook and return food. You do not walk into the walk-in freezer yourself. Many tables share one kitchen so recipes, inventory, and hygiene rules stay consistent.

Where the analogy stops: digital servers handle thousands of “tables” at once, can clone themselves behind a load balancer, and must survive network packets vanishing mid-order.

The problem without client–server

Everything local only

A pure offline spreadsheet on one laptop works offline—but teammates cannot share one live source of truth, and you cannot push a security fix to every copy instantly.

Everyone is a peer for everything

Peer-to-peer has uses (file sharing, some games, blockchains), but banking “every phone holds the ledger” is a nightmare for consistency, audit, and fraud control.

Client–server centralizes authoritative rules and data while clients stay replaceable.

Step-by-step explanation

Step 1 — Client gathers intent

User taps “Save note.” The client validates basic input (empty title?) and prepares a request.

Step 2 — Client sends a request over the network

Usually HTTP or HTTPS (Hypertext Transfer Protocol / Secure). Example idea: POST /notes with JSON body.

Step 3 — Server authenticates and authorizes

Who are you? (authentication)
May you create this note? (authorization)

Step 4 — Server executes business logic

Apply rules: length limits, spam checks, quota.

Step 5 — Server reads/writes durable storage

Database insert for the note row.

Step 6 — Server responds

Success with new noteId, or an error code the client can show.

Step 7 — Client updates the UI

Show the saved note or a clear error—not a silent failure.

Visual mental model

sequenceDiagram
  participant U as User
  participant C as Client app
  participant S as Server
  participant D as Database
U->>C: Tap Save
  C->>S: HTTPS request
  S->>S: Auth + rules
  S->>D: Write note
  D-->>S: OK
  S-->>C: 201 + noteId
  C-->>U: Show saved note

Learning question: If the database is down, which side should explain the failure to the user?

Caption: The server owns the truth; the client owns the experience of that truth.

Complete worked example: team notes app

Starting situation

Build a notes app for a 20-person team. Notes must sync across phones and laptops. Only the author can delete their notes.

Constraints

Must work on iOS, Android, web
One shared dataset
Password login
Small engineering team

Decisions

Piece	Choice	Why
Clients	Native/web apps	Multiple devices
Server	One HTTPS API	Single place for rules
Data	Postgres	Shared durable store
Auth	Session or token after login	Server enforces delete rights

Execution path

Login client → server verifies password hash → returns token.
Create note client → server checks token → inserts row with userId.
Delete note client → server checks note.userId == token.userId → delete or 403.

Failure behavior

Failure	Behavior
Server process dies	Clients see errors/timeouts until restart or second instance
Network drop after save	Client may retry; server should be idempotent for creates if possible
Malicious client	Server still enforces auth—never trust the client alone

Outcome

All devices share one notebook. Limitation: offline editing needs extra design (local queue + sync), still ultimately reconciling with the server.

How it works in production

Modern “one server” is often:

Many server instances behind a load balancer
Shared database
Optional cache

Still client–server: clients do not become the system of record.

Ownership

Frontend team owns clients
Backend team owns API + data rules
Clear API contracts prevent “it works on my mock” fights

Failure modes

Mode	Trigger	User impact	Mitigation
Server outage	Deploy/crash	App useless for online features	Multi-instance, health checks
Chatty client	Too many tiny requests	Slow UI, hot API	Batch, cache, pagination
Trusting the client	Validation only in UI	Security bugs	Server-side checks always
Fat client assuming LAN latency	Mobile on weak network	Spinners forever	Timeouts, offline UX
Version skew	Old app vs new API	Breakage	API versioning, graceful fields

Trade-offs

Choice	Benefit	Cost
Client–server	Shared truth, central security	Needs network; server is critical
Fully local	Works offline	Hard multi-user sync
Peer-to-peer	Less central infra	Consistency and abuse harder
Server-heavy logic	Easier rule updates	More round trips
Client-heavy logic	Snappy UI	Drift and security risk

Compare with related concepts

Concept	Relationship
API	The language clients use to talk to servers
Microservices	Many servers, still clients call them
Load balancing	Multiple server copies for one logical service
Peer-to-peer	Nodes act as both client and server roles

Common misunderstandings

“The browser is the server.”

The browser is a client. The server is elsewhere (or localhost in dev).

“If the UI hides a button, the action is impossible.”

Attackers call APIs directly. Server must enforce rules.

“Client–server is outdated because of microservices.”

Microservices are still servers; clients still call them.

“Servers must store session in memory.”

Prefer shared stores/tokens so any instance can serve the next request.

Check your understanding

Define client and server in one sentence each.
Why put delete permission checks on the server?
What is a round trip?
Name one failure that is not the server’s crash.
How does client–server differ from peer-to-peer?

Practice

List three clients you used today and what server they likely called.
Draw the save-note sequence including an auth failure.
Explain why “validation only in JavaScript” is unsafe.
Design offline: what does the client store until the server is back?
Map client–server onto a food-delivery app (customer app, restaurant app, backend).

Revision summary

Clients request; servers decide and store shared truth.
Network + API contract connect them.
Never trust the client for security rules.
Production multiplies servers but keeps the same roles.
This pattern is the base for almost all web system design.

Glossary

Term	Definition
Client–server architecture	Split into requestors (clients) and providers (servers).
Backend	Server-side systems.
Frontend	Client-side interface.
Stateless service	Handles each request without relying on sticky local memory.

Abbreviations and terminology

API — Application Programming Interface
HTTP / HTTPS — Hypertext Transfer Protocol (Secure)
UI — User Interface
JSON — JavaScript Object Notation (common request body format)

What to learn next

Deeper production notes

Horizontal scaling of the server tier

When one server process cannot handle all clients, you run many identical server instances behind a load balancer. Clients still believe they talk to one logical service. Session data should live in cookies/tokens or a shared store so any instance can handle the next request. Sticky sessions are a last resort and reintroduce single-instance pain when that instance dies.

Where business rules must live

UI validation improves usability. Authorization, pricing, and integrity rules must live on the server (or a trusted service the server calls). Otherwise a modified client or raw HTTP tool bypasses your product logic. Treat every request as potentially hostile or buggy.

Evolution path teams actually take

Single server + single database (fine for early products).
Multiple servers + shared database + reverse proxy.
Read replicas, caches, and async workers for hot paths.
Split services only when team or scaling boundaries demand it.

Skipping straight to step 4 without traffic or org pain usually adds outages without benefits. Client–server remains the mental model at every step.

Observability on the boundary

Log request ids on the client when possible and always on the server. Trace one user action across hops. Metrics that matter at the API edge: request rate, error rate, latency percentiles—not only CPU on one box.

FAQ from first-time learners

Q: Is the database the server?
A: The database is usually a dependency of the server. The API server is the client of the database.

Q: Can a server be a client?
A: Yes. Service A often calls Service B—A is B’s client.

Q: Do mobile apps change the model?
A: No. Mobile apps are clients; they still call servers for shared data.

Track: Software Design and Architecture

Previous: Batch vs Stream Processing — When to Wait, When to Flow

Next: Fan-out on Write vs Fan-out on Read

By Shubham Jain

All articles · Study paths

Shubham Jain · Learning Lab