Level 1 - Foundations #1. Client-Server Model

Source: Dev.to

👋 Short Intro (Why I’m Writing This)

I’m currently learning System Design and decided to learn in public by documenting my journey.

This blog is part of my System Design 101 series, where I’m learning System Design step‑by‑step from scratch.

Note: This series is not written by an expert — it’s a beginner learning out loud, sharing:

• what I understand,
• what confuses me,
• and what I learn along the way.

The goal is to build consistency, clarity, and invite discussion.

📌 What This Blog Covers

In this post, I’ll cover:

1. What the Client–Server model is
2. Who acts as a client and who acts as a server
3. How request–response communication works
4. What is inside an HTTP request and response
5. Stateless vs. stateful servers (with intuition)
6. Single‑server vs. multi‑server architectures

📂 GitHub Repository

All my notes, examples, and practice code live here:

[GitHub repo link]

The repo is updated as I continue learning.

📚 Learning Notes

1. What is the Client‑Server Model?

The simplest definition: we have two machines—one acts as a client, the other as a server.

• Client: requests something
• Server: responds with something

That’s the core of the Client‑Server model.

2. A Slightly Better Definition

The Client‑Server model is an architectural pattern where:

• The client initiates requests
• The server processes requests and returns responses
• They communicate over a network

Now let’s dive deeper into each component.

3. Who Is the Client?

A client is any entity that initiates a request.

Examples:

• Web browsers (Chrome, Firefox)
• Mobile apps (Android / iOS)
• CLI tools (curl, wget)
• Other backend services (micro‑services)

⚠️ Gotcha:

• A client is not always a browser.
• A backend can be a client to another backend.

4. Who Is the Server?

A server is a component that listens for client requests, processes them, and sends back responses.

Examples:

• Web servers (Node.js, Django, Spring)
• Database servers (PostgreSQL, MongoDB)
• File servers
• Authentication servers

Gotcha:

• “Server” is a role, not a specific machine.
• One machine can act as both client and server simultaneously.

5. The Request‑Response Flow

1. Client prepares a request
2. Client sends the request over the network
3. Server receives the request
4. Server processes the request
5. Server sends a response
6. Client receives the response

6. What Exactly Is Inside a Request?

A typical HTTP request contains:

• Method – what you want to do (GET, POST, PUT, PATCH, DELETE)
• Endpoint – e.g., /users
• Headers – authentication token, Content-Type, etc.
• Body (optional) – data you’re sending

Example

GET /users/123 HTTP/1.1
Authorization: Bearer xyz

7. What Exactly Is Inside a Response?

A typical HTTP response contains:

• Status code – e.g., 200 OK, 404 Not Found, 500 Server Error
• Headers – Content-Type, caching directives, etc.
• Body – JSON, HTML, binary data, etc.

Example

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

{
  "id": 123,
  "name": "Alice"
}

8. Stateless vs. Stateful Servers

Illustration

• Stateless: Client → Request A → Server and Client → Request B → Server (no shared state)
• Stateful: Server keeps session data between requests.

9. Single‑Server vs. Multi‑Server

• Single Server (early stage)

  • Suitable for MVPs or prototypes
  • Single point of failure
  • Limited scaling

• Multi‑Server (real world)

  • Multiple servers behind a load balancer that distributes traffic
  • Improves availability and scalability

10. A Real‑World Example (Putting It All Together)

When you open Instagram and refresh your feed:

1. Your mobile app (client) sends a request to Instagram’s servers.
2. The request passes through a load balancer.
3. One backend server processes the request.
4. The server fetches data from the database.
5. The server sends the response back.
6. Your app renders the feed on screen.

11. Why the Client–Server Model Matters in System Design

Almost every system‑design discussion starts with:

• Who is the client?
• Who is the server?
• How do they communicate?
• Where does state live?

Understanding this model is the foundation for:

• APIs
• Load balancing
• Scalability
• Microservices
• Caching

✅ Key Learnings & Takeaways

• Foundations of the Client‑Server model.
• How communication happens via a request‑response cycle.
• How load balancers and multiple backend servers work together.
• Basics of stateless vs. stateful servers.

If you faced any issues or have questions, let me know in the comments! 🙂

💬 Feedback & Discussion

I’d love your feedback!

If you notice:

• Something incorrect
• A better explanation
• Suggestions to improve my understanding

please comment below. I’m happy to learn and iterate.

⭐ **Support the Learning Journey**

If you find these notes useful:

- ⭐ Consider giving the GitHub repo a ⭐ star — it really motivates me to keep learning and sharing publicly.

🐦 **Stay Updated (Twitter / X)**  

I share learning updates, notes, and progress regularly.

🔜 **What’s Next**

In the next post, I’ll be covering:

- 👉 **OSI model / TCP‑IP fundamentals**

I’ll also continue updating the GitHub repo as I progress.

🙌 **Final Thoughts**

Thanks for reading!

If you’re also learning System Design, feel free to:

- follow along,  
- share your experience,  
- or drop questions in the comments 👋

What was fixed