Server-Client #

Server-client is suitable for applications that involve distributed data and processing across multiple components over a network.

Topology #

Example component diagram:

• Component
  • Clients: initiate requests (UI apps, tools, other services).
  • Servers: provide services/data to multiple clients.
• Connector: Remote communication
  • request/response (HTTP, REST, RPC) or message-based communication (queues/streams).
• Configuration: many clients can connect to the same server; servers can also call other servers.

Pros and cons #

• Pros
  • Clear distribution of responsibilities: clients vs servers.
  • Heterogeneous platforms: clients and servers can be built on different stacks.
  • Evolvability: servers can often be upgraded or replicated without changing clients if contracts are stable.
• Cons
  • Network failure modes become central concerns (latency, partial failure, retries, timeouts).
  • Service discovery and governance become harder as the number of servers grows.

Variants #

Microservices #

Microservices are suitable for complex applications that require short release cycles and high scalability. Each service typically implements one functionality, is deployed independently (often containerized), may own its database, and is managed by an orchestrator (e.g., Kubernetes) for deployment and auto-scaling.

Example topology (service mesh + API gateway):

Compared to basic server-client, the main topology change is the number of servers and connectors: there are many small servers, and server-to-server connectors (HTTP/RPC/messaging) become a large part of the system.

• Pros: independent deployability/scalability; better failure isolation.
• Cons: higher operational and architectural complexity (observability, contracts, distributed data).

Serverless (FaaS) #

Serverless is suitable when load is bursty and you prefer “pay-per-use”, and when cold-start/latency trade-offs are acceptable.

Serverless functions (FaaS):

• implement one simple functionality,
• triggered by events (HTTP, storage events, messages, …),
• are stateless between invocations,
• are ephemeral (short running).

Example topology:

Compared to microservices, serverless changes both the component lifecycle and the connectors: functions are invoked by event triggers (HTTP, storage events, queues), and state must be externalized to databases/queues/object storage. This is often a good match for event-driven tasks and spiky workloads, but it adds constraints around cold starts, timeouts, and vendor/platform coupling.

Real-world examples #

PostgreSQL (classic server-client database) #

PostgreSQL is a straightforward server-client system: the server provides a query interface, and many heterogeneous clients (apps, tools, services) connect concurrently. In terms of topology, the database server is the server component, client libraries/tools are clients, and the connector is the database protocol carrying SQL queries and results. Real deployments add connection pooling, replication, and access control to meet performance and reliability requirements.

Further reading: PostgreSQL documentation

Redis (server-client data store) #

Redis is another canonical server-client example: clients issue commands to a server over a protocol, and the server manages shared state. Here, the connector is the Redis serialization protocol (RESP) over TCP. Real deployments often add replication/clustering and client-side retry logic to handle partial failures and scaling.

Further reading: Redis documentation, RESP protocol specification

nginx (server-client at Internet scale) #

nginx is a high-performance HTTP server and reverse proxy that sits between clients and upstream servers. It illustrates a common server-client adaptation: adding an intermediary server component that terminates client connections and forwards requests to upstream servers. The connectors are still HTTP (and related protocols), but the topology now includes reverse proxying, load balancing, and caching.

Further reading: The Architecture of Open Source Applications: nginx, nginx documentation

Online Boutique (microservices demo) #

This demo decomposes an e-commerce app into many independently deployable services with their own APIs and data stores. From the topology point of view, each microservice is a server component, the API gateway and service-to-service calls are key connectors, and the deployment configuration (many independently scaled units) is part of the style.

Further reading: Google Cloud architecture: e-commerce microservices

Zuul (API gateway in microservice ecosystems) #

Zuul is an API gateway that fronts a fleet of backend services. In terms of topology, the gateway is a server component that all clients talk to; behind it are many server components (services). The connectors include HTTP/proxying between gateway and services, plus filter chains inside the gateway that implement cross-cutting concerns (auth, routing, rate limiting, monitoring).

Further reading: Zuul 2: The Netflix Journey to Asynchronous, Non-Blocking Systems, Open Sourcing Zuul 2

AWS Lambda sample applications (serverless / FaaS) #

AWS Lambda is a widely used example of serverless functions triggered by events (HTTP/API Gateway, queues, storage events). Mapping to topology: functions are the server-side components, triggers are connectors that invoke them, and persistent state is kept in external services (databases/queues/object storage) rather than in-memory between invocations.

Further reading: AWS Lambda Developer Guide

Google Cloud Functions samples (serverless / FaaS) #

Cloud Functions provides another concrete set of examples of event-triggered functions, illustrating vendor-specific constraints (timeouts, triggers, deployment packaging) that shape how the serverless variant is applied in practice.

Further reading: Google Cloud Functions documentation