Catalog
concept#Architecture#Software Engineering#Integration#Platform

Client–Server Model

An architectural pattern that separates systems into clients (requesters) and servers (service providers), defining clear responsibilities for presentation, processing, and storage.

The client–server model divides networked applications into service providers (servers) and requestors (clients), establishing clear responsibilities for processing, storage, and presentation.
Established
Medium

Classification

  • Medium
  • Technical
  • Architectural
  • Intermediate

Technical context

API gateways and reverse proxiesAuthentication services (OAuth, OpenID Connect)Monitoring and observability tools

Principles & goals

Clear separation of concerns between client and server.Design interfaces explicitly and stabilize them (versioning).Centralize sensitive business rules and data on the server.
Build
Enterprise, Domain, Team

Use cases & scenarios

Compromises

  • Overload of central services during traffic spikes.
  • Tight coupling due to poor API designs.
  • Server vulnerabilities have broad impact.
  • Ensure API versioning and backward-compatible changes.
  • Implement server-side validation and authorization centrally.
  • Use caching and CDNs to offload the server.

I/O & resources

  • Request profile and usage statistics
  • Specification of API endpoints
  • Scaling and SLA requirements
  • Defined client–server interfaces
  • Operational server components
  • Monitoring and alerting metrics

Description

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 isolation, and protocol selection.

✔

  • Simple assignment of responsibilities between components.
  • Enables centralized scaling and security.
  • Clients can remain lightweight and be evolved independently.

✖

  • Single point of failure for central servers without redundancy.
  • Scaling can become complex and costly (database, server state).
  • Network latency affects perceived client performance.

  • Response latency (p95)

    Measure of the 95th percentile latency for server responses to clients.

  • Error rate (HTTP 5xx)

    Proportion of server errors that affect clients.

  • Throughput (requests per second)

    Number of processed requests per unit time.

Typical web architecture (Browser ↔ API server)

Browser clients use HTTP APIs of a central server that hosts database and business logic.

Email system (mail client ↔ mail server)

Mail clients communicate with mail servers (IMAP/SMTP) for message management and delivery.

Data analysis tool with central processing instance

Lightweight analysis clients submit jobs to a powerful server that performs aggregation and storage.

1

Gather architectural goals and requirements.

2

Define interface design (API) and versioning strategy.

3

Implement, test, and deploy server components.

4

Introduce monitoring, logging and fault tolerance mechanisms.

⚠️ Technical debt & bottlenecks

  • Tight coupling between server modules without abstraction.
  • Insufficiently versioned APIs that block refactoring.
  • Monolithic database structure without migration strategy.
Database accessNetwork latencyServer CPU/memory
  • Placing all processing on a single server without redundancy.
  • Allowing clients direct DB access instead of going through APIs.
  • Missing rate limiting leading to DoS-like behavior.
  • Underestimating latency and network failures in client logic.
  • Ignoring consistency requirements for distributed data.
  • Excessive server state that prevents horizontal scaling.
Network protocols and HTTP fundamentalsAPI design and versioningServer operations, scaling and security
Scalability of server componentsSecurity and compliance requirementsLatency requirements and availability
  • • Protocol constraints (e.g. HTTP overhead)
  • • Existing legacy clients with fixed interfaces
  • • Regulatory requirements for centralized data storage