Client-Server Architecture: How a Web Request Travels Through a Modern Application

Introduction

Every time you open a website, search for something, log into an application, upload a photo, or place an order, a surprisingly large number of things happen behind the scenes.

You might think:

“I clicked a button, so the server gave me a response.”

But a modern application can involve:

Browser
   ↓
DNS
   ↓
Internet
   ↓
Load Balancer
   ↓
Web/API Server
   ↓
Cache
   ↓
Database
   ↓
Response

Understanding this request flow is one of the most important foundations of System Design.

Before learning about distributed systems, sharding, Kafka, microservices, or Kubernetes, you should understand how a basic client-server application works.

1. What Is Client-Server Architecture?

Client-server architecture is a model where responsibilities are divided between:

• Client
• Server

The client requests something.

The server processes the request and returns a response.

A simple example:

Client
  │
  │ Request
  ▼
Server
  │
  │ Response
  ▼
Client

The client could be:

• Web browser
• Android application
• iOS application
• Desktop application
• IoT device

The server could be:

• Web server
• API server
• Application server
• Database server
• Authentication server

2. A Real-World Example

Imagine you open:

https://example.com/products

Your browser doesn't magically know where example.com lives.

Several steps happen before you see the products.

A simplified flow is:

Browser
   ↓
DNS
   ↓
Server IP
   ↓
TCP/TLS Connection
   ↓
HTTP Request
   ↓
Server
   ↓
Application
   ↓
Database
   ↓
HTTP Response
   ↓
Browser

Let's understand each stage.

3. Step 1 — The User Makes a Request

You type:

https://example.com/products

into your browser.

The browser needs to find the server responsible for that domain.

This is where DNS comes in.

4. Step 2 — DNS Resolution

DNS stands for:

Domain Name System

Humans prefer names:

example.com

Computers communicate using IP addresses:

93.184.216.34

DNS translates the domain name into an IP address.

Conceptually:

example.com
     ↓
    DNS
     ↓
93.184.216.34

Without DNS, users would need to remember IP addresses for every website.

5. DNS Is More Than a Simple Lookup

A common beginner assumption is:

Domain → IP

In reality, DNS resolution can involve multiple layers of caching and different DNS servers.

A simplified hierarchy is:

Browser Cache
      ↓
Operating System Cache
      ↓
DNS Resolver
      ↓
Root DNS
      ↓
TLD DNS
      ↓
Authoritative DNS
      ↓
IP Address

Fortunately, most of the time cached information allows the process to be much faster.

6. Step 3 — Establishing a Connection

Once the client knows the server's IP address, it needs to communicate with it.

For a typical HTTPS connection, the process involves networking protocols such as TCP and TLS.

At a high level:

Client
  ↓
TCP Connection
  ↓
TLS Security
  ↓
HTTPS

TLS provides encryption and helps protect data exchanged between the client and server.

This is why modern websites generally use:

https://

instead of:

http://

7. Step 4 — The HTTP Request

Now the browser can send an HTTP request.

A simplified request might look like:

GET /products HTTP/1.1
Host: example.com

The request can contain:

• HTTP method
• URL/path
• Headers
• Query parameters
• Cookies
• Request body

Common HTTP methods include:

GET
POST
PUT
PATCH
DELETE

8. Understanding HTTP Methods

GET

Used to retrieve data.

GET /products

Example:

Give me the list of products.

POST

Used to create or submit something.

POST /orders

Example:

Create this order.

PUT

Usually used to replace/update a resource.

PUT /users/123

PATCH

Used for a partial update.

PATCH /users/123

Example:

Change only the user's phone number.

DELETE

Used to delete a resource.

DELETE /users/123

9. What Is an API?

API stands for:

Application Programming Interface

An API provides a structured way for software components to communicate.

For example:

Mobile App
     ↓
GET /api/products
     ↓
Backend API
     ↓
Database

The mobile application doesn't need to know how the database works.

It simply communicates through the API contract.

10. REST API

One of the most common API styles is REST.

A REST API might expose:

GET    /users
GET    /users/123
POST   /users
PATCH  /users/123
DELETE /users/123

For example:

GET /api/products/42

The server might respond:

{
  "id": 42,
  "name": "Laptop",
  "price": 79999
}

The frontend doesn't need to know whether the backend uses PostgreSQL, MySQL, MongoDB, or something else.

It only needs to understand the API contract.

11. API Gateway

In a simple application:

Client
  ↓
Application Server

But in a larger architecture, clients may communicate through an API Gateway.

                    ┌── User Service
                    │
Client → API Gateway ├── Order Service
                    │
                    ├── Payment Service
                    │
                    └── Product Service

The API Gateway can handle responsibilities such as:

• Routing
• Authentication
• Rate limiting
• Request validation
• Logging
• Monitoring
• Load distribution

This becomes particularly useful in microservice architectures.

12. Step 5 — Load Balancer

Imagine your application becomes popular.

One server is no longer enough.

You add:

Server 1
Server 2
Server 3

But who decides which server receives each request?

The load balancer.

                  ┌── Server 1
                  │
Client → Load Balancer ── Server 2
                  │
                  └── Server 3

Instead of sending every request to one server, traffic is distributed among multiple servers.

13. Why Load Balancing Matters

Suppose one server can handle:

1,000 requests/second

Your application receives:

3,000 requests/second

A single server won't be sufficient.

With three servers:

3 × 1,000
=
3,000 requests/second

In an idealized scenario, you have enough capacity.

Real systems are more complicated because workloads aren't always evenly distributed, but the fundamental idea remains.

14. Load Balancing Algorithms

Load balancers can distribute requests using different strategies.

Round Robin

Requests are distributed sequentially:

Request 1 → Server A
Request 2 → Server B
Request 3 → Server C
Request 4 → Server A

Least Connections

Send traffic to the server with the fewest active connections.

Weighted Distribution

More powerful servers receive more traffic.

For example:

Server A → 50%
Server B → 30%
Server C → 20%

The appropriate strategy depends on the workload.

15. Step 6 — Application Server

The request now reaches an application server.

Suppose the user requests:

GET /products

The application might:

1. Authenticate the user
2. Validate the request
3. Check permissions
4. Query a cache
5. Query the database
6. Transform the data
7. Return a response

Conceptually:

Request
   ↓
Application Logic
   ↓
Data Access
   ↓
Response

16. Step 7 — Database

Suppose the application needs product information.

It may query the database:

SELECT * FROM products;

The database returns the data.

Application Server
       ↓
     Query
       ↓
   Database
       ↓
    Results

The application then constructs the API response.

17. Step 8 — Caching

Now imagine thousands of users request the same product.

Without caching:

10,000 requests
      ↓
10,000 database queries

This can put unnecessary pressure on the database.

With a cache:

10,000 requests
      ↓
    Cache
      ↓
Most requests served here
      ↓
Only some requests reach DB

For example:

User
 ↓
API
 ↓
Redis
 ↓
Database

This can dramatically reduce database workload for suitable access patterns.

18. Cache Hit and Cache Miss

When an application checks the cache, there are two common outcomes.

Cache Hit

The requested data exists.

Request
  ↓
Cache
  ↓
Data Found ✓

The application can return the cached data.

Cache Miss

The data isn't available.

Request
  ↓
Cache
  ↓
Not Found
  ↓
Database
  ↓
Store Result in Cache
  ↓
Response

This basic pattern is called cache-aside or lazy loading.

We will explore caching deeply later in this series.

19. Step 9 — HTTP Response

Once the server finishes processing the request, it sends a response.

For example:

HTTP/1.1 200 OK
Content-Type: application/json

with:

{
  "products": [
    {
      "id": 1,
      "name": "Laptop"
    },
    {
      "id": 2,
      "name": "Keyboard"
    }
  ]
}

The client receives the response.

20. HTTP Status Codes

Status codes communicate what happened.

2xx — Success

200 OK
201 Created
204 No Content

3xx — Redirection

301 Moved Permanently
302 Found
304 Not Modified

4xx — Client-side problem

400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
429 Too Many Requests

5xx — Server-side problem

500 Internal Server Error
502 Bad Gateway
503 Service Unavailable
504 Gateway Timeout

Understanding these codes is important when debugging distributed systems.

21. The Complete Request Journey

Let's put everything together.

Suppose a user requests:

https://shop.example.com/products/42

A simplified architecture could look like:

                 ┌──────────────┐
                 │     DNS      │
                 └──────┬───────┘
                        │
                        ▼
                    Internet
                        │
                        ▼
                ┌───────────────┐
                │ Load Balancer │
                └───────┬───────┘
                        │
              ┌─────────┴─────────┐
              ▼                   ▼
        Application 1       Application 2
              │                   │
              └─────────┬─────────┘
                        ▼
                    ┌───────┐
                    │ Cache │
                    └───┬───┘
                        │
                    Cache Miss
                        │
                        ▼
                   ┌─────────┐
                   │Database │
                   └─────────┘

The response travels back to the client.

22. Where Can Things Go Wrong?

System Design becomes interesting when we stop assuming everything works perfectly.

Consider this architecture:

Client
  ↓
Load Balancer
  ↓
Application
  ↓
Database

What happens if the database crashes?

Client
  ↓
Load Balancer
  ↓
Application
  ↓
Database ❌

Your application may become unusable.

What if the application server crashes?

Application 1 ❌
Application 2 ✓

A load balancer can potentially route traffic to the healthy server.

This demonstrates an important principle:

A system should be designed with failure in mind.

23. Single Point of Failure

A Single Point of Failure (SPOF) is a component whose failure can bring down the entire system.

Consider:

Users
  ↓
Single Server
  ↓
Database

If the server fails:

Application ❌

Instead, we can introduce redundancy:

             ┌── Server 1
Users → LB ──┤
             └── Server 2

Now one application server can fail without necessarily taking down the entire service.

But redundancy itself isn't enough.

What if the load balancer is a single point of failure?

Users
  ↓
Single Load Balancer ❌
  ↓
Servers

Now the load balancer becomes the bottleneck and failure point.

This is why System Design requires us to examine the entire architecture, not just individual components.

24. Stateless Application Servers

Suppose you have:

Server A
Server B
Server C

A user logs in through Server A.

If Server A stores all session information only in its own memory, the next request going to Server B could cause problems.

One solution is to keep shared state outside the application servers.

For example:

Server A ──┐
Server B ──┼── Redis
Server C ──┘

Now all application servers can access the same session state.

This makes horizontal scaling easier.

25. Stateful vs Stateless

Stateful

The server maintains client-specific state locally.

User
 ↓
Server A
 ↓
Local Session

Stateless

The server doesn't rely on locally stored session state.

User
 ↓
Server A
 ↓
Shared State Store

or the request carries enough information for the server to process it independently.

Stateless architecture is often easier to scale horizontally.

26. What Happens When Traffic Increases?

Imagine:

1,000 users

Your architecture works perfectly.

Then:

100,000 users

Now problems appear.

The database becomes overloaded.

You add caching.

Then:

1,000,000 users

Now application servers need to scale.

You add more servers.

Then:

10,000,000 users

You may need:

• Database replication
• Database partitioning
• Message queues
• Multiple cache nodes
• CDN
• Multiple regions
• Asynchronous processing

This is the fundamental journey of System Design:

Simple Architecture
        ↓
Growing Traffic
        ↓
Bottlenecks
        ↓
Optimization
        ↓
Scaling
        ↓
Distributed Architecture

27. Performance vs Scalability

These concepts are often confused.

Performance

How quickly can the system complete a task?

Example:

Request latency = 50 ms

Scalability

How well does the system handle increasing workload?

Example:

1,000 requests/sec
        ↓
10,000 requests/sec
        ↓
100,000 requests/sec

A system can be very fast for a small workload but difficult to scale.

Likewise, a highly scalable system might sacrifice some latency for greater throughput.

System Design is about balancing these requirements.

28. A Modern E-Commerce Architecture

Let's apply everything we've learned.

Imagine an e-commerce platform.

A simplified architecture might be:

                    Users
                      │
                      ▼
                     DNS
                      │
                      ▼
                     CDN
                      │
                      ▼
               Load Balancer
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
      API Server   API Server   API Server
          │           │           │
          └───────────┼───────────┘
                      │
          ┌───────────┼────────────┐
          ▼           ▼            ▼
        Cache      Database     Queue
                                  │
                                  ▼
                               Workers

Different components solve different problems.

29. Don't Add Components Just Because They Are Popular

A major System Design mistake is architecture by buzzword.

Someone might draw:

Kubernetes
Kafka
Redis
MongoDB
PostgreSQL
Elasticsearch
Microservices
CDN
GraphQL

and call it a scalable architecture.

But architecture isn't a shopping list.

Every component should solve a specific problem.

For example:

Why do we need Redis?

Possible answer:

Because product data is frequently read and caching it reduces database load and latency.

That's a meaningful architectural decision.

But:

“Because Redis is used in large companies.”

is not a design reason.

30. The Golden Rule of System Design

When designing a system, repeatedly ask:

What problem am I solving?

For example:

Problem: Too many requests hitting one server.

Solution: Horizontal scaling + load balancing.

Problem: Database reads are too expensive.

Solution: Caching, query optimization, replicas, or other appropriate techniques.

Problem: Long-running background work makes APIs slow.

Solution: Asynchronous processing with queues and workers.

Problem: Large static files create latency and origin load.

Solution: CDN and object storage.

This problem → solution mindset is much more valuable than memorizing technologies.

31. System Design Interview Perspective

In a System Design interview, you may receive a question like:

“Design a URL shortener.”

Don't immediately draw:

Redis
Kafka
MongoDB
Kubernetes

Instead, start by asking questions.

Functional requirements

• Can users create short URLs?
• Should URLs expire?
• Should users customize aliases?
• Do we track clicks?

Non-functional requirements

• How many users?
• How many URLs?
• How many redirects per second?
• What latency is acceptable?
• How available must the service be?

Then estimate scale.

Then design the simplest architecture that satisfies the requirements.

Then identify bottlenecks.

Then improve the design.

That is how strong System Design interviews are approached.

32. A Repeatable Design Process

Throughout this series, we'll use a consistent methodology.

Step 1 — Clarify Requirements

Understand what the system needs to do.

Step 2 — Estimate Scale

Estimate:

• Users
• Requests
• Storage
• Bandwidth

Step 3 — Define APIs

Determine how clients interact with the system.

Step 4 — Design Data Model

Determine what information must be stored.

Step 5 — Create High-Level Architecture

Identify major components.

Step 6 — Identify Bottlenecks

Ask:

What will break first?

Step 7 — Scale the Bottlenecks

Introduce appropriate solutions.

Step 8 — Discuss Reliability

Ask:

What happens when something fails?

Step 9 — Discuss Trade-Offs

Explain why one approach was selected over another.

Final Takeaway

A modern web request is not simply:

Browser → Server

It can look more like:

Client
  ↓
DNS
  ↓
Internet
  ↓
Load Balancer
  ↓
API/Application Servers
  ↓
Cache
  ↓
Database
  ↓
Queue/Workers
  ↓
Response

Each component exists because it solves a particular problem.

The most important lesson isn't memorizing this diagram.

It is learning to ask:

What problem does this component solve?

As applications grow, new problems appear:

More users
    ↓
More traffic
    ↓
More data
    ↓
More failures
    ↓
More complexity

System Design is the discipline of managing that complexity while keeping the system scalable, reliable, performant, and maintainable.