Loading content
The client–server model divides networked applications into service providers (servers) and requestors (clients), establishing clear responsibilities for processing, storage, and presentation. It underpins many internet and enterprise systems, enabling centralized resources and independent client evolution. It guides design choices around scalability, fault…
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What you need to understand to reason about a domain.
The client–server model separates networked applications into requesters and service providers: clients initiate interactions, while servers provide functions, data, or resources. This makes it easier to separate presentation, processing, and storage.
The model emerged from the need to structure networked applications as a distributed messaging pattern: a client initiates communication, and a server waits for requests and offers shared resources. On the web, HTTP made this request-response logic between browser and server especially explicit and practical across different systems.
Think of it as a front desk plus back office. The client is the front end: it collects user input, forms a request, and displays the result. The server is the shared service and data side: it checks the request, runs business logic, reads or writes data, and sends a response back. Both roles can live on separate machines or in the same system.
The requesting side starts the communication and usually handles direct user interaction.
The providing side offers shared services, data, or resources and processes incoming requests.
A client sends a request; the server returns a response within the same communication flow.
Work is split according to whether it runs on the client or on the server.
Shared rules and interfaces define how client and server exchange and interpret messages.
The model is useful when an application should provide central data or services to many users, such as on the web, in APIs, or in enterprise systems. It supports scaling, maintenance, and independent evolution of the interface and the logic. The trade-offs are dependence on network quality, latency, server availability, and the risk that the server becomes a bottleneck.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.