Behind Every Click: Understanding Client–Server Architecture

Source: Dev.to

Client–server architecture is one of the most fundamental models used in modern application development.

• Client – the user or application making the request
• Server – the machine that processes the request and returns the response

When a user wants to access a server, the simplest method is by pinging the server’s IP address. However, IP addresses are difficult to remember, which makes direct access impractical. To solve this problem, we use the Domain Name System (DNS).

A server with limited hardware (e.g., 2 CPUs and 4 GB RAM) can process only a certain number of requests. When traffic increases significantly, users may experience delays or the server may become unresponsive.

Scaling Strategies

Vertical Scaling (Scaling Up)

Increasing the physical resources of a single server, such as upgrading to 16 CPUs and 128 GB RAM.

Pros

• Simpler architecture (single server)

Cons

• Resource wastage when traffic is low
• Downtime during scaling, since the server needs to be restarted
• Hardware limits – there is a maximum capacity beyond which upgrades are not possible

Horizontal Scaling (Scaling Out)

Duplicating multiple small servers with the same configuration (e.g., multiple 2‑CPU, 4‑GB‑RAM servers).

Pros

• No downtime when adding or removing servers
• Better cost efficiency
• High fault tolerance
• Efficient traffic management during peak times

Consideration

• Each cloned server receives its own IP address, raising the question: How do we handle multiple server IPs if DNS points to only one?

Handling Multiple Server IPs

When multiple servers exist, a load balancer typically sits in front of them. The load balancer receives traffic directed at a single DNS name and then distributes requests across the pool of server IPs based on a chosen algorithm (e.g., round‑robin, least connections, weighted distribution).

Critical Design Considerations

• Load balancing decision logic – How does the load balancer decide which server to send each request to?
• Session persistence – How do we maintain user sessions across multiple servers (e.g., login sessions)?
• Auto‑scaling – How do auto‑scaling groups work when traffic increases suddenly?
• Shared storage – How do applications store shared files when servers are distributed?
• Health checking – How does health‑checking ensure that traffic is never sent to a failed server?