Loading content
Client-server architecture separates functions between clients that request services and servers that provide resources. It defines communication patterns, responsibilities, and scaling models for distributed systems. Common use cases include web, database, and application services; architecture decisions must balance latency, consistency, security, and oper…
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.
Client-server architecture separates requesting clients and serving servers into distinct roles so distributed systems can provide services, data, and compute through defined communication paths.
The pattern emerged with distributed applications and networked systems, when software no longer ran only locally but requested services across machine boundaries. To make shared resources such as data, compute, and output manageable, designers described a division of labor between clients that ask for service and servers that provide it. The separation supports clear responsibilities, protocols, and security boundaries.
Think of a service counter: the client makes a request, the server checks it, processes it, and sends back a response. Multiple clients can use the same server instance or a server cluster. In many systems, presentation, business logic, and data storage sit in different roles or layers; protocols, authentication, and load balancing regulate who can reach what, when, and how.
A reusable structural principle organizes a system's components, responsibilities, and interactions.
One role requests services while the other provides them, creating the basic split of responsibilities.
Communication usually happens as a request followed by a reply, often over a network.
Shared rules define message shape, sequence, and expected behavior between both sides.
Multiple servers, caching, or load balancing help absorb growing demand and workload.
The separation creates control points for authentication, authorization, and protecting sensitive resources.
The architecture is useful for web, database, and API systems, and whenever central services must serve many users reliably. It fits well when clear responsibilities, shared data, or controlled access matter. Typical trade-offs are network latency, dependence on server operation, and extra effort for availability, scaling, and security.
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.