Hello! Welcome to your fifth lesson in the Foundations of System Architecture.
In our last lesson, we established the "First Law of Software Architecture": everything is a trade-off. We saw that an architect's primary job is to analyze these trade-offs and make decisions that align with business goals.
Today, we will apply that thinking to the most fundamental architectural pattern for networked applications: the client-server pattern. This pattern is the bedrock upon which the web and most modern software systems are built. Your goal is to be able to describe this pattern and its common variations, understanding the "why" behind its structure and the trade-offs it embodies.
By the end of this lesson, you will be able to explain the core client-server model and describe its key variations, including 1-tier, 2-tier, 3-tier, and n-tier architectures.
The Client-Server Model: A Fundamental Separation
At its core, the client-server model is a distributed application structure that partitions tasks between providers of a resource or service, called servers, and service requesters, called clients.
While your experience in IT infrastructure has made you very familiar with physical servers, here we're focusing on how this logical separation between client and server roles impacts software design and application structure.
To start, let's watch a short video that uses a simple analogy to introduce this concept.
System Design - Part 2 | Client-Server Architecture | Examples w/ Advantages and Disadvantages
This video from Nikhil Lohia's system design series uses a bookstore analogy to explain the basic relationship between a client and a server.
Watch the first 5 minutes and 23 seconds of the video. Focus on the core roles: the client requests information, and the server provides it.
As the video explains, the key principle is a separation of responsibilities:
- The Client: An application or device that initiates requests. Its primary concern is often presentation and user interaction (e.g., a web browser, a mobile app). It knows how to ask for things but doesn't need to know how the work is done.
- The Server: An application or machine that waits for and fulfills client requests. Its concerns are business logic, data processing, and storage. It provides a service without knowing how the results will be presented.
This separation is the pattern's biggest strength and also the source of its inherent trade-offs.
The Trade-Offs of Client-Server Architecture
By separating the client and server, we gain significant advantages but also introduce new challenges. Let's explore these, which directly relate to the quality attributes we've discussed.
System Design - Part 2 | Client-Server Architecture | Examples w/ Advantages and Disadvantages
Let's continue with the same video, which now discusses the advantages and disadvantages of this model.
Watch from 05:23 to 13:59. As you watch, try to map the pros and cons discussed to the architectural trade-offs from our previous lesson (e.g., scalability vs. reliability).
To summarize the key trade-offs:
| Advantage (Why we use it) | Disadvantage (The resulting problem) |
|---|---|
| Centralized Management: Logic and data are managed in one place (the server), making updates and control easier. A change on the server is instantly available to all clients. | Single Point of Failure: If the server goes down, all clients are affected. This creates a need for reliability patterns like redundancy. |
| Scalability: You can scale the server independently of the clients. If more users join, you can upgrade the server hardware or add more servers without changing the client application. | Network Congestion & Latency: Communication happens over a network, which is slower than in-process calls and can become a bottleneck. Performance is a key concern. |
| Flexibility: A single server can support many different types of clients (web, mobile, desktop), as long as they speak the same protocol (e.g., HTTP). | Security Risks: The server is a central target for attacks. The network itself must be secured. This creates a need for firewalls, encryption, and authorization. |
This model forces us to trade the simplicity of a single, monolithic application for the scalability and flexibility of a distributed one, accepting the new challenges of reliability, performance, and security.
Variations: Tiered Architectures
The basic client-server model can be organized in many ways. The most common approach is to further break down the "server" side into logical layers, or tiers. A tier is a logical and often physical separation of components and responsibilities.
The following article provides a clear, structured overview of these variations.
Client-Server Architecture 2025: Tiers, Cloud, Edge AI & ...
This article from Ismail Kovvuru on Medium gives an excellent deep dive into the classic tier models, which are direct evolutions of the client-server idea.
Please read the section titled '3. Deep Dive: Classic Client Tier Models'. Focus on understanding the definition, examples, and pros/cons of 1-Tier, 2-Tier, 3-Tier, and n-Tier architectures.
Let's recap and visualize these tiers.
1-Tier Architecture
All components—UI (presentation), business logic, and data storage—reside on a single machine. Think of a simple Python script that uses a local SQLite database. It's simple and fast to develop but doesn't scale and isn't accessible remotely.
2-Tier Architecture
This is the classic client-server model.
- Tier 1 (Client): Handles presentation (UI) and business logic. This is often called a "fat client."
- Tier 2 (Server): Manages the data storage (database).
An example would be a desktop application (like an old internal accounting tool) that connects directly to a central database server over the company network.
3-Tier Architecture
This is the most common pattern for web applications. It introduces a middle tier to decouple business logic from the client.
- Tier 1 (Presentation): The user interface. Typically a web browser rendering HTML/CSS/JavaScript or a mobile app. This is a "thin client."
- Tier 2 (Application/Logic): An application server that executes business logic. It receives requests from the presentation tier, processes them, and interacts with the data tier.
- Tier 3 (Data): The database server that stores and manages data.
The primary benefit of the 3-tier model is separation of concerns. The client doesn't need to know anything about the database, which improves security and allows each tier to be developed, scaled, and updated independently.
N-Tier Architecture
This is an extension of the 3-tier model where the application is split into more than three tiers. For example, you might add a caching tier, a message queue tier, or an API gateway. Microservice architectures are a form of n-tier architecture.
.png)
Test your understanding!
A company has a simple internal admin tool built 15 years ago. It's a desktop application installed on employees' computers, and it connects directly to a central SQL database on the company network to manage inventory.
- What tier architecture is this?
- What is one major security risk associated with this design?
- How does a 3-tier architecture mitigate this risk?
Show answer
- This is a 2-Tier architecture. The desktop application (the client) contains both the presentation and business logic, and it connects directly to the database (the server).
- The major security risk is that the client has a direct connection to the database. This means database credentials must be managed on each client machine, and the database server is exposed to a wider part of the network, increasing the attack surface.
- A 3-tier architecture mitigates this by placing an application server between the client and the database. The client only communicates with the application server, never the database. The application server is responsible for authenticating requests and managing a secure, limited connection to the database. This drastically reduces the exposure of the data tier.
From Code Logic to Physical Tiers
It's important to see how the logical organization of code translates into a physical, tiered architecture. A common pattern for organizing code within a single application is Model-View-Controller (MVC). A 3-tier architecture can be seen as a physical deployment of this logical separation.
Introduction to System Design - MVC and Three-Tier Architecture
To make this more concrete, the following video shows how an application's logical components (Model, View, Controller) can be physically separated into the services that form a 3-tier architecture. The specific technology examples are very helpful.
Watch from 13:43 to 21:40. Pay attention to: How the 'View' becomes the frontend service (Presentation Tier). How the 'Controller' and 'Model' become the backend service (Application Tier). How the database becomes its own service (Data Tier). The mapping to real-world services like AWS S3, EC2, and RDS.
The video provides a perfect bridge from your infrastructure knowledge to software architecture.
- Presentation Tier (Frontend): A React app hosted on AWS S3 (object storage for static files).
- Application Tier (Backend): A Django/Python application running on AWS EC2 (virtual servers).
- Data Tier (Database): A PostgreSQL database managed by AWS RDS (managed database service).
Each tier can be scaled independently. If your application logic is computationally intensive, you can add more EC2 instances without touching the database or the frontend. This is the power of the tiered approach.
Conclusion
In this lesson, we explored the client-server pattern, the foundation of modern distributed systems. We saw that it's not a single pattern but a model with several important variations, primarily tiered architectures. Each variation represents a different set of trade-offs between simplicity, scalability, security, and performance.
Key Takeaways:
- The client-server pattern separates requesters (clients) from providers (servers), enabling centralized management and independent scalability.
- This separation introduces trade-offs, primarily exchanging the simplicity of a single machine for the complexities of network communication, reliability, and security.
- Tiered architectures are variations that further subdivide the server's responsibilities into distinct layers.
- 2-Tier (client-database) is simple but couples logic to the client and poses security risks.
- 3-Tier (Presentation, Application, Data) is the standard for web applications, providing excellent separation of concerns, which enhances security, maintainability, and independent scalability.
- N-Tier architectures extend this by adding more specialized layers (caching, messaging, etc.) to handle the demands of large-scale systems.
The client-server pattern and its tiered variations are perhaps the most powerful example of a core principle in software design. In our next lesson, we will formally define and explore this principle: separation of concerns.