Client–server model - Scaling and Architectural Variants

Centralized Computing versus Rich Clients Introduction When designing systems that deliver computation and services to users, architects must choose between different approaches to distribute resources and processing power. The two fundamental paradigms—centralized computing with rich clients, and peer-to-peer networking—represent distinct trade-offs in how computing resources are allocated and how systems scale. Centralized Computing and Rich Clients Centralized computing concentrates computing resources on a small number of powerful central servers. Instead of requiring every user's device to be powerful, the heavy computational work happens on these central machines, and client machines simply request results. In contrast, a rich client (such as a personal computer) has significant computational power, memory, and storage of its own. A rich client can perform substantial work independently and does not rely on a server for essential functions. For example, your laptop can edit documents, run applications, and process data without needing to send every task to a remote server. These two approaches represent opposite ends of a spectrum. Centralized computing maximizes resource efficiency by consolidating power in fewer machines. Rich client computing maximizes user control and responsiveness by distributing capability to each user's device. Client-Server Architecture versus Peer-to-Peer Networks The way computing resources are organized fundamentally changes how systems work and scale. Structural Differences In a client-server architecture, the relationship is hierarchical. Servers are centralized systems that service many clients. Clients make requests, and servers respond with data or services. Because a single server must handle requests from many clients, the server requires sufficient computing power, memory, and storage to meet the expected workload. As demand grows, the server must be upgraded or replaced with a more powerful machine. In a peer-to-peer (P2P) network, the structure is fundamentally different. Two or more computers—called peers—pool their resources together and communicate directly in a decentralized, non-hierarchical system. Each peer acts simultaneously as both a client and a server. There is no central bottleneck, and resources are distributed throughout the network. The choice between these architectures affects scalability. Client-server systems can become bottlenecks when the server is overwhelmed, but they're simpler to manage and secure. P2P systems can be more resilient and avoid single points of failure, but they're more complex to coordinate. Load Balancing in Client-Server Systems As a client-server system grows and handles more requests, a single server often cannot keep up. Load balancing solves this by distributing network or application traffic across multiple servers in a server farm, improving both efficiency and availability. Here's how it works: A load balancer sits between client devices and the backend servers. When requests arrive, instead of going directly to one server, they first go to the load balancer. The load balancer then forwards each request to an available server that is capable of handling it. This distribution ensures that no single server becomes overwhelmed, and requests complete faster. For example, imagine a web service with three backend servers. Without load balancing, all 1,000 requests per second might hit the first server, causing it to crash. With load balancing, the 1,000 requests are distributed—perhaps 333 to each server—so each server handles a manageable workload. Redundancy and Failover Even with load balancing, systems can fail. To maintain reliability, client-server architectures often employ redundancy and failover systems. Redundancy means having backup copies of critical systems. Failover is the automatic process of switching from a failed primary system to a backup system. Together, they provide high availability—the system continues operating even when a primary server fails. For example, if a primary database server crashes, a failover system automatically redirects traffic to a standby database server that was already running in parallel. Users may not notice any interruption, or experience only a brief pause while the failover occurs. This is in contrast to rich client systems, where each client is responsible for its own data and computation, so there's no single server to fail. However, this also means there's no central backup strategy—each client must manage its own redundancy.