Does client-server require separate machines?

No. The processes can communicate locally or across a network.

Is a database client necessarily a graphical tool?

No. It can be any compatible application, including another server.

Does a timeout prove the server did nothing?

No. The operation may have completed even if the response did not reach the client.

AI Glossary / Data engineering and architecture / Beginner

Client-Server Architecture

Definition

Client-server architecture organizes software into components that request services and components that provide them. A client initiates a request, and a server handles it through an agreed interface or protocol. The roles describe an interaction, not necessarily two physical machines: one program can be a server in one relationship and a client in another.

What it means

A web browser requests a page from a website server. The website's application may then request data from a database server. In the first interaction the application serves the browser; in the second it acts as a database client.

Separating these responsibilities lets many clients use a shared service while the server manages common data or operations. Clients might be browsers, mobile apps, command-line tools or other automated services.

The architecture does not require a public internet connection or a cloud provider. Client and server processes can run on one computer or communicate across a network. Their locations affect deployment and reliability, but do not determine the basic roles.

How it works

The client sends a request using the service's protocol, including the operation and relevant data. The server checks the request, applies the required logic and returns a response or another defined result. Some systems also support asynchronous messages or ongoing connections.

The server may authenticate the requester and authorize the operation before accessing protected resources. Input validation must occur at the relevant trusted boundary. A browser form that prevents invalid input is useful for users, but a client can be modified or replaced, so the server cannot rely on the form alone.

Clients and servers need compatible expectations about message formats, errors and versions. They also need timeouts and a policy for retries. A missing response can mean the request never arrived, the server is still working or the operation completed but the response was lost.

Multiple server instances, load balancers, caches and database tiers can sit behind one visible endpoint. Client-server architecture describes the service relationship; it does not imply a single server process must carry the entire workload.

Three practical examples

A desktop reporting tool sends SQL requests to a database server and displays the returned results.
A mobile shopping app requests catalog data and submits orders to a backend service that enforces the business rules.
An AI assistant acts as a client of a model-serving API, while its own backend acts as a server for the user interface.

Think of it this way

Think of a reception desk that receives requests and coordinates work with specialist departments. A visitor asks the desk for help, and the desk may itself request information from a records office.

The analogy shows how a component's role depends on the interaction. It has limits: software messages need exact formats, requests can overlap and network failures can hide whether work completed. The architecture needs explicit handling for those cases rather than assuming a conversation always ends with an understood answer.

Worked example

Tracing one request across two service relationships

An invented library app displays a book's availability. The browser sends a request containing BookID B42 to the application server. The application validates the identifier and uses its permitted database connection to query the relevant record.

The database server returns the recorded availability. The application converts that into the response format expected by the browser, which displays it. The browser is the application client; the application is the database client.

Suppose the next operation is reserving the book. The server must recheck availability under appropriate concurrency rules when processing that operation. A previously displayed available label is not a guarantee that another user has not reserved it meanwhile.

The separation of roles makes the request path understandable, but consistency requires additional design. Returning a page, reading a record and successfully committing a reservation are distinct events, even when they occur within one user journey.

Illustrative case study

A fictional booking company hides an administrator-only button in its ordinary users' browser interface. The backend nevertheless accepts the corresponding operation from any logged-in user, because it assumes only administrators can see the button.

Testing with a direct request reveals the gap. The team adds an authorization check to the server operation and verifies both permitted and denied cases. The interface still hides irrelevant controls, but that presentation choice no longer carries the access-control responsibility.

The case illustrates a boundary inherent in client-server systems: the server must evaluate the requests it receives, not infer permission from how its preferred client normally behaves. Other clients, scripts or modified applications may use the same interface.

Common misconceptions and mistakes

Client means a person's laptop and server means a large remote computer. These are software roles; they can coexist on one host.
A server cannot also be a client. A backend commonly serves one component while requesting another service.
Client-side validation is sufficient. Trusted services must enforce the rules required for the operations they perform.

Business use

Client-server architecture helps centralize shared data and capabilities while allowing different user interfaces. It can support independent updates, resource sharing and clearer ownership of services.

Map the request path before diagnosing a slow or failed user action. Delays can arise in the client, network, application, database or an external dependency. Logging a request identifier across those boundaries can help locate the problem without assuming that the visible interface caused it.

For AI products, identify where prompts, documents and responses travel and which identity each service uses. Define limits, timeouts and retry handling for model calls as well as ordinary database requests. A well-designed client should communicate uncertainty when an operation's outcome is unknown instead of reporting success solely because it sent a request.

Check your understanding

A website backend receives a browser request and then queries a database. Is the backend a client or a server?

Answer: Both, in different interactions. It serves the browser and acts as a client when requesting database services.

Related terms

Response
Client
server
API
request
protocol
authentication
authorisation
multi-tier architecture
timeout

Learn next

Read request-response protocols and service boundaries. Draw one application action across browser, backend and database, marking each client-server relationship and where validation and authorization occur.

Response

Sources

PostgreSQL, Architectural Fundamentals: https://www.postgresql.org/docs/17/tutorial-arch.html. Primary explanation of database clients, servers and process roles.

MDN, Client-server overview: https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Server-side/First_steps/Client-Server_overview. Primary developer documentation of web request handling.

MDN, HTTP messages: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Messages. Primary developer documentation of request and response messages. The library and booking cases are original illustrations.

Previous: CLEVER score Next: Client-side persistent data