Client–Server Architecture
The foundational pattern underneath almost every digital product: one side asks, the other side answers.
1.3.1Definition
Client–server architecture separates a system into two roles. The client is the program a person interacts with directly — a browser tab, a mobile app, a desktop application. The server is a program running elsewhere, usually on infrastructure the user never sees, that holds data, enforces rules, and does the work the client cannot or should not do itself. The client sends a request; the server processes it and sends back a response.
1.3.2Why It Exists
Before this split was standard, software often ran entirely on one machine, with data and logic living together, inaccessible to anyone else. Client–server architecture exists to solve three problems at once: letting many clients share one authoritative source of data, letting that data be updated centrally without updating every client, and letting sensitive logic (pricing rules, permissions, private data) run somewhere the client can't tamper with.
browser / app
business logic
1.3.3When to Use It — and When Not To
Use client–server whenever more than one person needs to see the same data, whenever data must persist beyond a single session, or whenever any logic needs to be protected from the end user. This covers the overwhelming majority of digital products. It is not the right frame for purely local, single-user tools with no shared state and no sensitive logic — an offline calculator or a local text editor gains nothing from a server and only adds latency, cost, and a new failure mode.
1.3.4Advantages and Disadvantages
| Advantages | Disadvantages |
|---|---|
| Centralized, consistent data across all users | Requires network connectivity to function |
| Logic and secrets stay off the client, harder to tamper with | Server becomes a single point of failure unless designed for redundancy |
| Updates ship once, centrally — clients don't need reinstalling | Adds latency compared to fully local computation |
| Scales to many simultaneous users via one backend | Introduces real operational cost: hosting, monitoring, scaling |
1.3.5Common Mistakes
- Trusting the client. Validating input, checking permissions, or calculating prices only in client-side code, then trusting whatever the server receives. The server must independently verify everything that matters.
- Treating the server as infinitely available. Designing a client with no meaningful behavior when the server is slow or unreachable, rather than handling timeouts, retries, and offline states deliberately.
- Overloading a single server role. Letting one server handle authentication, business logic, file storage, and email as tightly coupled code, making it impossible to scale or replace any one piece independently.
1.3.6Best Practices
- Treat every request from a client as untrusted input until the server validates it.
- Design explicit client states for "loading," "offline," and "server error" — don't let these be accidental blank screens.
- Keep the boundary intentional: UI state and formatting on the client, authority over data and rules on the server.