Skip to main content
System Design Interview
CHAPTER 03 Beginner

Client-Server Architecture

Updated: May 18, 2026
5 min read

# CHAPTER 3

Client-Server Architecture

1. Chapter Introduction

The foundation of the modern internet—and every system design interview—is the Client-Server model. Before you can scale databases or implement microservices, you must profoundly understand how a user's device communicates with a backend system. This chapter breaks down the exact lifecycle of a web request, the crucial role of DNS, and the architectural separation between Web Servers and Application Servers.

2. The Client-Server Model

In distributed computing, the architecture is divided into two distinct entities:
  • The Client (The Requestor): The end-user's device. This could be a web browser (Chrome), a mobile app (iOS/Android), or an IoT device. Clients are responsible for rendering the UI and sending requests.
  • The Server (The Provider): A powerful computer (or cluster of computers) hosted in a data center. Servers wait for requests, process business logic, query databases, and return responses back to the client.

*Key Principle:* Clients should NEVER directly access the database. The server acts as the secure middleman.

3. DNS (Domain Name System) Basics

Computers communicate using IP Addresses (e.g., 192.168.1.1 or 2001:0db8::ff00). Humans cannot remember billions of IP addresses. DNS is the "Phonebook of the Internet." It translates human-readable domain names (e.g., www.google.com) into machine-readable IP addresses.

The DNS Lookup Process:

  1. 1. You type facebook.com into your browser.
  1. 2. The browser checks its local cache.
  1. 3. If not found, it queries an ISP DNS Resolver, which queries Root servers, TLD servers, and finally the Authoritative Name Server.
  1. 4. The DNS returns the IP Address (e.g., 157.240.22.35) back to the browser.
*Note: In system design interviews, DNS is usually treated as an external service managed by third parties (like AWS Route53 or Cloudflare).*

4. The HTTP Request Lifecycle

Once the client has the IP address, the real communication begins. You must be able to whiteboard this flow:
  1. 1. TCP Handshake: The client establishes a reliable TCP connection with the server (SYN, SYN-ACK, ACK).
  1. 2. HTTP Request: The client sends an HTTP GET/POST request containing headers, cookies, and payloads.
  1. 3. Processing: The server receives the request, executes business logic, and queries the database.
  1. 4. HTTP Response: The server sends back an HTTP response with a status code (e.g., 200 OK) and data (usually JSON or HTML).
  1. 5. Rendering: The client's browser parses the JSON/HTML and renders the UI.

5. Web Servers vs. Application Servers

In modern, scalable system design, the "Server" is often split into two distinct tiers:

1. The Web Tier (Web Servers):

  • *Examples:* Nginx, Apache.
  • *Function:* Handles raw HTTP traffic. Serves static content (HTML, CSS, Images). Manages SSL termination and connection handling. If the request requires dynamic logic, it forwards it to the App Server.

2. The Application Tier (App Servers):

  • *Examples:* Node.js, Spring Boot (Java), Django (Python).
  • *Function:* Executes complex business logic, processes payments, running algorithms, and communicates directly with the database.

*Why split them?* Separation of concerns. Web servers are optimized for handling thousands of concurrent lightweight HTTP connections. App servers are optimized for heavy CPU computation.

6. Architectural Diagram: The 3-Tier Architecture

This is the baseline architecture you will draw in your interviews.
text
12345678910111213141516171819202122 
       [ CLIENT ] (Browser / Mobile App)
           |
       (Internet)
           |
           v
  [ LOAD BALANCER ]
           |
    +------+------+
    |             |
[ WEB TIER ]   [ WEB TIER ]  <-- (Nginx: Serves Static Assets)
    |             |
    +------+------+
           |
  [ LOAD BALANCER ]
           |
    +------+------+
    |             |
[ APP TIER ]   [ APP TIER ]  <-- (Node.js/Python: Business Logic)
    |             |
    +------+------+
           |
     [ DATABASE ]

7. HR/Interview Perspective: Protocol Knowledge

Interviewers will test your depth by asking, "Why use HTTP over UDP for this request?" You must know that HTTP (which runs on TCP) guarantees packet delivery, ensuring data isn't lost during a checkout process. If you are designing a live video stream, you might suggest UDP, which is faster but allows packet loss (glitches).

8. Real-World Scenario: Static Asset Bottleneck

*Scenario:* A startup hosts their marketing website on a single Django (Python) App Server. Every time a user loads the page, Django has to process and serve a 5MB background image. The site slows to a crawl under heavy load. *The Fix:* The engineers place an Nginx Web Server in front of Django. Nginx is configured to serve the 5MB image directly from disk in milliseconds, without ever waking up the Python App Server. The App Server is now free to process dynamic API requests exclusively.

9. Mini Project: Trace a Request

Verbally trace exactly what happens when a user clicks "Login" on a website.
  1. 1. Browser resolves DNS.
  1. 2. Browser sends HTTP POST request with username/password over HTTPS.
  1. 3. Request hits Load Balancer.
  1. 4. Request routed to App Server.
  1. 5. App Server hashes password and queries Database.
  1. 6. App Server generates JWT (JSON Web Token) and sends HTTP 200 Response.
  1. 7. Browser stores token and redirects to Dashboard.

10. Common Mistakes

  • Assuming direct DB access: Never draw a line directly from the Client (Mobile App) to the Database. This is a massive security violation. All DB access must go through the Application Server.
  • Forgetting DNS: In global system design (e.g., Netflix), DNS is used to route users to the data center physically closest to them to reduce latency.

11. Best Practices

  • Stateless Architecture: Ensure both your Web and App tiers are stateless. Any server should be able to handle any request.
  • HTTPS: Always mention that communication between the Client and the Load Balancer occurs over HTTPS (encrypted), even if internal network traffic is HTTP.

12. Exercises

  1. 1. What is the difference between a 404 HTTP status code and a 500 HTTP status code?
  1. 2. If you want to design a multiplayer shooting game, would you prioritize TCP or UDP?

13. MCQs

Question 1

What is the core definition of the Client-Server model?

Question 2

Why should a Client (like a mobile app) NEVER communicate directly with the Database?

Question 3

What is the primary function of DNS (Domain Name System)?

Question 4

What is the first step that occurs before an HTTP request can be sent from a client to a server?

Question 5

What is the primary difference between a Web Server and an Application Server?

Question 6

In a standard 3-Tier Architecture, what are the three tiers?

Question 7

Which HTTP method is traditionally used to submit data to the server to create a new resource (e.g., submitting a login form)?

Question 8

Why might Nginx be placed in front of a Node.js application server?

Question 9

What does an HTTP 200 OK status code indicate?

Question 10

In global system design, how can DNS help reduce latency for users?

14. Interview Questions

  • Q: "Walk me through exactly what happens when you type www.amazon.com into your browser and press Enter, down to the network layer."

15. FAQs

  • Q: Are Web Servers and App Servers always on different physical machines?
A: In massive scale, yes. But in smaller applications, Nginx (Web Server) and Node.js (App Server) often run on the exact same physical machine, just listening on different ports.

16. Summary

The Client-Server architecture separates the UI from the business logic. DNS translates domain names to IPs, allowing the client to initiate a TCP handshake and send an HTTP request. To build scalable systems, engineers implement a 3-Tier Architecture, separating Web Servers (static content/connections) from App Servers (business logic) and Databases (storage), allowing each layer to scale independently.

17. Next Chapter Recommendation

With the servers receiving requests, they need somewhere to permanently store the data. In Chapter 4: Databases and Data Storage, we will dive deep into Relational Databases, ACID properties, and the magic of indexing.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Previous Chapter Understanding Scalability Fundamentals
Next Chapter Databases and Data Storage

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·

Explore More

📖 Related Tutorials 4

🗺️ Related Roadmaps 1