Client Server Architecture
Learn the request-response mental model that underpins modern products.
Curriculum
System Design Foundations
Scalability Basics
Database Design
Client Server Architecture — Beginner Friendly System Design Guide
The Foundation Of Every Modern App
Almost every modern application works on one simple idea:
Client sends request → Server sends response
This is called:
Client-Server Architecture
Whether you use:
- Swiggy
- YouTube
- PhonePe
- IRCTC
all follow this model.
Simple Real-Life Analogy
Restaurant Example
Imagine you go to a restaurant.
You (Client)
You:
- read menu
- place order
- wait for food
Kitchen (Server)
Kitchen:
- processes request
- prepares food
- sends response
Real Mapping
| Real World | Computer World |
|---|---|
| Customer | Client |
| Kitchen | Server |
| Order | Request |
| Food | Response |
What Is A Client?
Client is the application used by user.
Examples:
- mobile app
- browser
- desktop app
Real Examples
| Product | Client |
|---|---|
| Swiggy | Mobile App |
| YouTube | Browser/App |
| Paytm | Mobile App |
| Mobile App |
What Is A Server?
Server is a machine/program that:
- processes requests
- handles business logic
- accesses databases
- returns responses
Real Examples
| Company | Server Responsibility |
|---|---|
| Swiggy | Restaurant search |
| Ola | Driver matching |
| PhonePe | Payment processing |
| Netflix | Video streaming |
Simple Request-Response Flow
Suppose you open Swiggy.
App asks:
"Show restaurants near me"
Server processes request and responds with restaurant list.
Basic Flow Diagram
Client (Mobile App)
│
▼
API Request
│
▼
Application Server
│
▼
Database / Cache
│
▼
API Response
│
▼
Client Shows UI
Step-by-Step Example — Swiggy
Step 1 — User Opens App
User taps Swiggy icon.
Step 2 — Client Sends Request
Swiggy app sends:
GET /restaurants?city=jaipur
Step 3 — Server Receives Request
Server checks:
- user location
- available restaurants
- ratings
- offers
Step 4 — Server Accesses Database
Database contains:
- restaurants
- menus
- prices
- delivery partners
Step 5 — Server Sends Response
Server returns:
[
{
"name": "Dominos",
"rating": 4.3
}
]
Step 6 — Client Renders UI
Swiggy app displays restaurants.
Complete Swiggy Architecture Flow
User Opens Swiggy
│
▼
Mobile App (Client)
│
▼
HTTP/API Request
│
▼
Load Balancer
│
▼
Application Server
│
┌──────┼──────┐
▼ ▼
Redis Database
Cache
│
▼
Response Returned
│
▼
Restaurants Displayed
Why Client-Server Architecture Exists
Before this model:
- applications stored everything locally
- updates were difficult
- data sharing impossible
Client-server architecture solved this.
Benefits
| Benefit | Why Important |
|---|---|
| Centralized logic | Easier updates |
| Shared data | Multiple users access same system |
| Better security | Logic stays on server |
| Easier scaling | Add more servers |
| Better maintenance | Server updates instantly affect all users |
Example — WhatsApp
Client
WhatsApp mobile app:
- shows chats
- sends messages
- displays UI
Server
WhatsApp servers:
- route messages
- manage delivery
- store media
- authenticate users
WhatsApp Message Flow
Sender Mobile App
│
▼
WhatsApp Server
│
▼
Receiver Mobile App
Thin Client vs Thick Client
Thin Client
Most logic handled by server.
Examples:
- websites
- cloud apps
Thick Client
More logic handled on client.
Examples:
- games
- video editing apps
Comparison
| Thin Client | Thick Client |
|---|---|
| Server-heavy | Client-heavy |
| Easier updates | Faster offline |
| Less device power needed | More local processing |
Example — YouTube
Client Responsibilities
YouTube app:
- video player
- UI rendering
- buffering
Server Responsibilities
YouTube servers:
- video delivery
- recommendations
- ads
- subscriptions
YouTube Request Flow
User Clicks Video
│
▼
YouTube App
│
▼
API Request
│
▼
YouTube Servers
│
┌──────┼────────┐
▼ ▼
Recommendation Video CDN
System
│
▼
Video Stream Returned
Stateless vs Stateful Servers
Stateless Server
Server does NOT remember previous requests.
Every request is independent.
Most APIs follow this.
Example
GET /products
Server processes request independently.
Stateful Server
Server remembers user session/state.
Examples:
- gaming servers
- live chat systems
Example — Online Game
Server tracks:
- player position
- health
- active session
Scaling Client-Server Systems
As traffic grows:
- one server becomes insufficient
Need:
- load balancing
- horizontal scaling
Example — IPL Streaming On Hotstar
Millions watch simultaneously.
Single server cannot handle traffic.
Scaled Architecture
Users
│
▼
Load Balancer
│
┌─┼─────────┐
▼ ▼ ▼
App1 App2 App3
│
▼
Database Cluster
Real Indian Examples
| Company | Client | Server Responsibility |
|---|---|---|
| Swiggy | App | Food ordering |
| Ola | Rider App | Driver matching |
| Zerodha | Trading UI | Order execution |
| IRCTC | Website/App | Ticket booking |
| PhonePe | App | Payment processing |
Common Beginner Misconceptions
"Frontend Does Everything"
No.
Frontend mostly:
- sends requests
- displays data
Actual business logic usually runs on server.
"Database Directly Talks To User"
No.
Usually flow is:
Client
│
▼
Server
│
▼
Database
Database is protected behind server.
"One Server Means One Machine"
Not always.
Modern systems may use:
- hundreds of servers
- microservices
- distributed systems
behind one app.
Client-Server + APIs
Modern communication usually happens using APIs.
API Flow
Client App
│
▼
API Request
│
▼
Server
│
▼
Database
│
▼
JSON Response
│
▼
Client UI Updated
Final Mental Model
Client = User Interface
Server = Brain + Processing
Database = Storage
Final Architecture Diagram
User
│
▼
Client App / Browser
│
▼
Internet
│
▼
Load Balancer
│
▼
Application Server
│
┌────┼─────┐
▼ ▼
Cache Database
│
▼
Response Returned
│
▼
UI Updated
One-Line Interview Definition
Client-server architecture is a distributed computing model where clients send requests to centralized servers that process logic, access data, and return responses over a network.
Module context
How the internet actually works, the client-server model, databases, and APIs. The building blocks every architect needs before anything else.