Client-Server Architecture

What is Client-Server Architecture — and Why Does It Exist?

The client-server model is a way of distributing a computing task between two cooperating roles: a client that initiates a request, and a server that listens for requests, processes them, and returns a response. Every layer of the modern web — a browser talking to a REST API, a microservice calling another microservice, a mobile app syncing data — is an instance of this same pattern.

It exists to solve a concrete problem: where should application logic, data, and control over both live? Before this model was standard, that question was answered in two bad ways — either everything lived on one expensive central machine (the mainframe era), or business logic and direct database credentials were baked into every desktop client that shipped (the two-tier era). Both put the wrong things in the wrong place. Client-server architecture — and specifically its three-tier evolution — separates presentation, business logic, and data storage into independently deployable, independently scalable layers.

/*
 * BEFORE — two-tier: the desktop client talks directly to the database.
 * Business rules and database credentials live inside every installed copy
 * of the client. This was completely standard in the 1990s and is still
 * the default mistake newcomers make when they first connect a UI to a DB.
 */
public class OrderDesktopClient {
    public void placeOrder(Long productId, int quantity) throws SQLException {
        // The client owns a raw JDBC connection with real DB credentials.
        // Anyone who decompiles this .jar has your database password.
        Connection conn = DriverManager.getConnection(
            "jdbc:postgresql://prod-db:5432/shop", "app_user", "h4rdc0d3d");

        // Business rule ("check stock before selling") lives in the CLIENT.
        // Every desktop installation must be updated to change this rule,
        // and a malicious or buggy client can simply skip the check.
        ResultSet rs = conn.prepareStatement(
            "SELECT stock FROM products WHERE id = " + productId).executeQuery();
        if (rs.next() && rs.getInt("stock") >= quantity) {
            conn.prepareStatement(
                "UPDATE products SET stock = stock - " + quantity +
                " WHERE id = " + productId).executeUpdate();   // SQL injection too
        }
    }
}

/*
 * AFTER — three-tier: the client only knows an HTTP contract.
 * Business logic and data access move behind a server the client never sees.
 */
@RestController
@RequestMapping("/api/orders")
public class OrderController {

    private final OrderService orderService;   // constructor injection

    public OrderController(OrderService orderService) {
        this.orderService = orderService;
    }

    @PostMapping
    public OrderResponse placeOrder(@Valid @RequestBody OrderRequest request) {
        // Credentials never leave the server. The stock rule can change
        // without touching a single client. The client only ever sees JSON.
        return orderService.placeOrder(request);
    }
}

// The client's entire responsibility is now this:
HttpRequest req = HttpRequest.newBuilder()
    .uri(URI.create("https://shop.example.com/api/orders"))
    .header("Content-Type", "application/json")
    .POST(HttpRequest.BodyPublishers.ofString(json))
    .build();

Client and Server Are Roles, Not Machines

The single most common misunderstanding when developers first meet this model: assuming "client" and "server" describe fixed types of hardware or software. They don't. They describe who initiated the request in a given exchange. The exact same process can be a server in one connection and a client in another, simultaneously.

// A single Spring Boot application, two roles at once:

                    Acts as SERVER                Acts as CLIENT
                    (for the browser)             (for the database)
                          │                             │
┌──────────┐         ┌────┴─────────────────────────────┴────┐         ┌──────────┐
│ Browser  │ Request │                                       │ Query   │ Postgres │
│ (Client) │ ──────▶ │           OrderController             │ ──────▶ │ (Server) │
│          │ ◀────── │                 ↓                     │ ◀────── │          │
└──────────┘ Response│           OrderService                │ Result  └──────────┘
                      │                 ↓                     │
                      │           PaymentClient  ──────────▶  │  Payment Service
                      └───────────────────────────────────────┘  (server, elsewhere)

// In a microservice chain the same rule holds at every hop:
Order Service ──(client)──▶ Payment Service ──(client)──▶ Fraud-Check Service

This matters in real code, not just in diagrams. A service class that calls out to another microservice is acting as a client the moment it does so — and should be built with the same discipline you'd expect from any HTTP client: timeouts, retries, and circuit breakers, because the "server" on the other end can fail or be slow just like any external dependency.

@Service
public class OrderService {

    private final OrderRepository orderRepository;
    private final PaymentClient paymentClient;   // this class is a CLIENT

    public OrderService(OrderRepository orderRepository, PaymentClient paymentClient) {
        this.orderRepository = orderRepository;
        this.paymentClient = paymentClient;
    }

    public OrderResponse placeOrder(OrderRequest request) {
        Order order = orderRepository.save(new Order(request.productId(), request.quantity()));

        // OrderService is a client of PaymentService here — same failure modes
        // as any external HTTP call: it can time out, it can 5xx, it can be slow.
        PaymentResult result = paymentClient.charge(order.id(), request.amount());

        return new OrderResponse(order.id(), result.status());
    }
}

The Three Components: Client, Server, and Network

The Client

A client's job is to gather intent from a user (or another system), turn it into a well-formed request, send it, and do something useful with whatever comes back. It does not need to know how the server fulfills the request — only the contract for asking.

The Server

A server binds to a port, listens continuously, and for each incoming connection: authenticates the caller, authorizes the action, executes business logic, touches whatever data store it needs, and serializes a response. Spring Boot and Jakarta EE containers handle the socket plumbing and threading for you — your code only has to fill in the business-logic step.

// Server side — modern Spring Boot 3.x, constructor injection, record DTOs
@RestController
@RequestMapping("/api/products")
public class ProductController {

    private final ProductService productService;

    public ProductController(ProductService productService) {
        this.productService = productService;   // single constructor → @Autowired not needed
    }

    @GetMapping("/{id}")
    public ProductResponse getProduct(@PathVariable Long id) {
        return productService.findById(id);   // never return the JPA entity directly
    }

    @PostMapping
    @ResponseStatus(HttpStatus.CREATED)
    public ProductResponse createProduct(@Valid @RequestBody ProductRequest request) {
        return productService.create(request);
    }
}

// DTOs are records — immutable, no proxy needed, no accidental lazy-loading
// of JPA associations leaking into a JSON response.
public record ProductRequest(@NotBlank String name, @Positive BigDecimal price) {}
public record ProductResponse(Long id, String name, BigDecimal price) {}

The Network: Layers and Ports, Just Enough to Debug Confidently

Day to day you work almost entirely at the application layer (HTTP). But when a connection refuses, times out, or gets blocked by a firewall, knowing which layer you're debugging saves hours.

A port identifies which application on a machine should receive the traffic — the IP address gets you to the host, the port gets you to the right process.

// Ports worth memorizing:
Port 80    →  HTTP  (unencrypted)
Port 443   →  HTTPS (encrypted — the production default)
Port 8080  →  Common Spring Boot development default
Port 5432  →  PostgreSQL
Port 3306  →  MySQL
Port 6379  →  Redis

// One host, several independently deployed services on different ports:
192.168.1.100
├── :8080 → user-service
├── :8081 → order-service
└── :8082 → payment-service

Architecture Patterns: Two-Tier, Three-Tier, and Microservices

Two-Tier — Client Talks Directly to the Database

┌──────────┐              ┌──────────┐
│  CLIENT  │  ──────────▶ │ DATABASE │
│ (Desktop)│  ◀────────── │ (MySQL)  │
└──────────┘              └──────────┘

// Still seen in legacy internal tools and quick scripts.
// Acceptable for a single trusted internal user; wrong for anything
// exposed to the public internet — see Section 0's before/after example.

Three-Tier — The Default for Good Reason

┌──────────┐       ┌──────────┐       ┌──────────┐
│  CLIENT  │ ────▶ │  SERVER  │ ────▶ │ DATABASE │
│ (Browser)│       │ (Spring  │       │ (Postgre │
│          │ ◀──── │   Boot)  │ ◀──── │   SQL)   │
└──────────┘       └──────────┘       └──────────┘
                        │
              ┌─────────┴─────────┐
         Presentation        Business logic
          (Controllers)         (Services)

// One deployable server holds business logic; database credentials never
// leave it; the client is replaceable (web, mobile, CLI) without touching
// the rules that govern the business.

N-Tier / Microservices — Splitting the Middle Tier Itself

┌──────────┐       ┌─────────────────────────────────────┐
│  CLIENT  │ ────▶ │            API Gateway               │
└──────────┘       └─────────────────────────────────────┘
                                   │
                    ┌──────────────┼──────────────┐
                    ▼              ▼              ▼
              ┌──────────┐  ┌──────────┐  ┌──────────┐
              │   User   │  │  Order   │  │ Payment  │
              │ Service  │  │ Service  │  │ Service  │
              └────┬─────┘  └────┬─────┘  └────┬─────┘
                   ▼             ▼             ▼
              ┌──────────┐ ┌──────────┐ ┌──────────┐
              │  User DB │ │ Order DB │ │Payment DB│
              └──────────┘ └──────────┘ └──────────┘

// Each service is independently deployable and independently scalable —
// the trade-off is that "the server" is no longer one thing you can reason
// about locally: distributed failure modes replace in-process ones.

Stateless vs Stateful Servers

This decision shapes how easily your server scales horizontally, and it is made per-endpoint, not just per-application.

// STATELESS — every request is self-describing; any instance can serve it
@GetMapping("/api/profile")
public UserResponse getProfile(@RequestHeader("Authorization") String bearerToken) {
    Long userId = jwtService.extractUserId(bearerToken);
    return userService.findById(userId);
}

// STATEFUL — the server must remember which instance holds this session
@GetMapping("/api/profile")
public UserResponse getProfile(HttpSession session) {
    Long userId = (Long) session.getAttribute("userId");
    return userService.findById(userId);
}

Session and cookie mechanics — how a session ID actually gets to the server on every request, and what a load balancer does with sticky sessions — are covered fully in Sessions & Cookies. JWT structure and validation are covered in JWT (JSON Web Tokens).

Best Practices and Common Pitfalls

Interview Questions