Client Server
A client-server system splits a networked application into two roles: a server, a program that waits for requests and holds some shared resource such as a web page, a database, a file store or a computation, and a client, a program that starts the conversation by sending a request and then uses the reply. The two roles are about behavior rather than hardware. A laptop can run a server process, one machine can run dozens of servers, and a single program such as a web server may itself act as a client when it asks a database for data. The model is the organizing idea behind the web, email, online banking, multiplayer games and nearly every mobile app.
The basic mechanic is request and response: the client opens a connection to a known address and port, sends a message that says what it wants, and the server does the work and sends back a result or an error. A browser asking for a page sends an HTTP request naming a path and a method such as GET or POST; the server answers with a status code such as 200 or 404 and a body. Servers listen on well-known ports (80 for HTTP, 443 for HTTPS, 25 for SMTP mail) over transports such as TCP, and a single server handles many clients at once by running each connection on a separate thread, process or event-loop task. Because HTTP is stateless, each request must carry everything the server needs, such as a session cookie or token, to recognize who is asking, which is why login state is a deliberate design decision rather than something the protocol provides.
The main alternative is peer-to-peer, where every participant is both client and server and no machine has a privileged role. Napster in 1999 and later BitTorrent used this shape to share files, with each peer uploading pieces to others, and Bitcoin's network follows the same idea for agreeing on a ledger. Peer-to-peer scales by adding participants and has no single point of failure, but it is harder to secure, update, search and keep consistent. Client-server concentrates control: one place to enforce permissions, apply a software fix, back up data and bill for usage, at the price of a central machine that can be overloaded or can fail. Many real systems blend both, such as video calls that use a server to introduce participants and then send media directly between them.
Clients differ in how much work they do, and the thin versus thick distinction describes where the logic lives. A thin client does little more than display results and send input; the classic examples are text terminals attached to a mainframe and, in a modern form, a plain web page whose content is built on the server. A thick (or fat) client carries real logic and often local data, as with a desktop spreadsheet, a game or a mobile app that caches information and works offline. Single-page web applications blur the line by shipping a large amount of JavaScript to the browser while still depending on server APIs. Thin designs ease updates and keep sensitive data off the device, while thick designs respond faster and tolerate poor connectivity; the common three-tier layout of presentation, application logic and database puts a different server role at each layer.
Scaling and failure shape most of the engineering around the model. A popular server is placed behind a load balancer that spreads requests across many identical machines, caches such as a content delivery network answer repeated requests early, and timeouts and retries let a client survive a slow or dead server. Retrying has a pitfall: if a payment request is sent twice because the first reply was lost, the server may charge twice unless the operation is designed to be idempotent. Everything a client sends is also untrusted input, since anyone can write a client; checks done only in the browser, such as form validation, can be bypassed and must be repeated on the server, a point that belongs to cybersecurity practice rather than to the model itself.
A frequent misconception is that a server is a special kind of powerful computer. Any computer, including a Raspberry Pi or a phone, becomes a server the moment it runs a program that accepts requests, and a cloud data center is just very many ordinary machines doing so. The reverse confusion also occurs: "the client" is not always a person, since a script, a smartphone app, a microservice or a machine-learning pipeline calling an inference API are all clients. In machine learning, a hosted model is typically exactly this pattern, with a lightweight client sending a prompt over HTTPS and a GPU-equipped server returning the generated text.
Read client-server as a division of labor over a network: whoever asks is the client, whoever answers is the server, and every design choice, from stateless requests to thin or thick clients to load balancers, is about where to place the work, the data and the trust.