Client-Server Style

## What the style is The client-server style is one of the oldest and most common **structural patterns** in software architecture: a system is decomposed into two kinds of participants with different responsibilities, connected by a **request-response protocol** over a network (or, in degenerate cases, over IPC on one machine). | Participant | Its job | |---|---| | **Client** | The initiator — it holds the user-facing responsibility, gathers input, and sends a request describing what it wants. | | **Server** | The responder — it owns a shared resource (a database, a set of business rules, a piece of hardware) and processes incoming requests, returning a response that the client then interprets and presents. | ## How one exchange runs Mechanically, the interaction follows a strict turn-taking sequence: 1. The client opens a connection (or reuses one), serializes a request according to an agreed-upon protocol (an HTTP method + path + body, an RPC call, a SQL query over a wire protocol), and sends it. 2. The server, which has been listening on a known address, accepts the request, parses it, executes whatever logic or query it implies, and serializes a response back down the same channel. 3. The client is passive between sending and receiving: it does not do anything else meaningful with that request until the response arrives. Crucially, the server does not initiate contact with a client on its own — it cannot "push" unprompted work to a client to whom it hasn't been asked to. ## Why the separation exists The style exists to solve a **resource-and-responsibility separation problem**. Data and business logic are often expensive, sensitive, or need to be shared across many consumers — a product catalog, a customer database, an authentication check — so it doesn't make sense to duplicate that logic into every client. - By centralizing it behind a server, you get a **single place** to enforce validation rules, apply security controls, and keep data consistent, while clients stay focused on presentation and user interaction. - This also lets the two sides **evolve independently**: a mobile app team and a web team can both talk to the same backend without knowing about each other, and the backend team can change its internal implementation as long as the request/response contract is preserved. ## The trade-offs The trade-offs are real on both sides. - **Shared dependency.** Centralizing logic on the server means the server becomes a shared dependency: if it's down, every client is affected — the classic single-point-of-failure risk, mitigated in practice by replication and load balancing, but that mitigation is extra operational cost the style itself doesn't provide for free. - **Latency.** Network round-trips introduce latency that a purely local, single-process design wouldn't have; a chatty protocol (many small requests) can be dramatically slower than a design that batches work. - **Concurrency.** The server must also handle concurrency: many clients hitting it at once means it needs threading, connection pooling, or async I/O, and a naive implementation can be overwhelmed. - **Connectivity.** On the client side, if the client does little beyond rendering, it becomes fully dependent on connectivity — a poor fit for offline or high-latency environments. ## Failure modes in production Failure modes in production typically show up as **timeouts and partial failures** rather than clean errors: a client sends a request, the server is slow or unreachable, and the client has to decide whether to - retry, - show a stale cached value, or - surface an error to the user. Because the server is shared, a bug or overload in the server's logic affects every client simultaneously — unlike a bug in one client's local logic, which affects only that user. **Debugging** also becomes distributed: a failure might originate in the network, the client's serialization, or the server's processing, and correlating logs across the two sides is a real operational skill. ## Where you have already seen it - **A concrete example:** a web browser (client) requesting a page from a web server is the canonical instance — the browser sends an HTTP `GET`, the server queries a database and renders HTML, and the browser displays it. - **Another everyday instance** is a mobile banking app talking to a REST API: the app never touches the bank's database directly — it goes through the server, which enforces authentication, business rules, and audit logging, none of which the client is trusted to enforce itself.