Catalog
concept#Architecture#Platform#Integration#Security

Client-Server Architecture

An architecture pattern that separates clients and servers into roles and defines communication and scaling principles for distributed systems.

Client-server architecture separates functions between clients that request services and servers that provide resources.
Established
Medium

Classification

  • Medium
  • Technical
  • Architectural
  • Intermediate

Technical context

Load balancer / reverse proxyRelational or NoSQL databasesCaching layer (e.g., Redis)

Principles & goals

Clear separation of responsibilities between client and serverExplicit interfaces and contract-based communicationDesign for scalability and fault tolerance
Build
Enterprise, Domain, Team

Use cases & scenarios

Compromises

  • Server overload without appropriate scaling strategy
  • Security vulnerabilities in central services compromise many clients
  • Inconsistencies under concurrent access without proper coordination
  • Use established API standards (REST, gRPC) and versioning
  • Implement redundant servers and health checks
  • Plan observability (logging, tracing, metrics) from the start

I/O & resources

  • Client requests / user data
  • Server resources (CPU, memory, storage)
  • Network connections and protocols
  • Responses to clients
  • Persistent data storage
  • Operational monitoring and logs

Description

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 operational cost.

✔

  • Centralized management of resources and security
  • Easier scaling of server components
  • Reusable services for different clients

✖

  • Single point of failure if servers are not redundantly provisioned
  • Network latency and bandwidth dependence
  • Potential scaling costs under high traffic

  • Response time (p95)

    Latency guarantee for 95% of requests.

  • Throughput (requests/sec)

    Number of processed requests per second as a capacity measure.

  • Error rate

    Proportion of failed responses relative to total requests.

Typical web architecture

Browser client communicates with a REST API running on a server that uses a relational database.

Database server architecture

Various clients access shared data via a central database server; access control centralized.

Microservice-aligned client-server variant

Lightweight server services perform specialized tasks; clients coordinate multiple services for user functionality.

1

Perform requirements analysis and define role model

2

Design interfaces (API contracts)

3

Implement and test server components

4

Establish operations, scaling and monitoring

⚠️ Technical debt & bottlenecks

  • Ad-hoc endpoints without API contract and tests
  • Lack of automation for scaling and deployment
  • No observability implemented for critical paths
Database lock contentionNetwork latencySingle-threaded server components
  • All logic in one central server that becomes a bottleneck
  • Insecure APIs without authentication in production
  • Stateful servers without a strategy for failure scenarios
  • Underestimating network latency with distributed clients
  • Lack of capacity planning leads to sudden bottlenecks
  • Neglected security reviews before production rollout
Network and protocol knowledgeServer and infrastructure managementSecurity and authentication strategies
Scalability and load distributionSecurity and access controlAvailability and fault tolerance
  • • Limited bandwidth and latency constraints
  • • Legacy protocols or incompatible clients
  • • Regulatory requirements for data storage