Clients, Servers & the Life of a Request

In one line

Every system is programs talking to other programs over a network. A client asks, a server answers. Follow one click from a browser to a database and back, and every later topic is a variation of this trip.

0/5 · 0%

Think of it like this

A restaurant. You (the CLIENT) don't walk into the kitchen; you tell a waiter what you want. The waiter (the SERVER) takes your order to the kitchen, which fetches ingredients from the pantry (the DATABASE), and the waiter brings back your plate (the RESPONSE). Many diners, one kitchen: that's a server handling many clients.

Key ideas

01
A CLIENT is any program that starts a conversation: a browser, a mobile app, another backend service, a script. A SERVER is a program that waits for requests and answers them, usually running on a machine in a data centre or cloud. The same program can be both: your order service is a server to the app and a client of the payment service.
02
What happens when you tap 'Buy': 1) the app looks up the server's address from its name (DNS, like a phone book); 2) it opens a connection over the internet (TCP, with encryption from HTTPS); 3) it sends an HTTP REQUEST such as POST /orders with the order details; 4) the server runs code, reads and writes the database, maybe calls other services; 5) it sends back a RESPONSE (201 Created plus the order ID); 6) the app shows 'Order placed!'. Typical total: 100–300 ms.
03
Why this matters for design: every arrow in a system diagram is one of these request/response trips, and every trip costs time and can fail. System design is mostly deciding HOW MANY trips, BETWEEN WHAT, and WHAT HAPPENS WHEN ONE FAILS.
04
SYNCHRONOUS vs ASYNCHRONOUS: in a synchronous call the client waits for the answer (like standing at the counter). In an asynchronous design the client drops off a message and leaves (like posting a letter); someone processes it later. Both appear everywhere, and choosing between them is a core design decision (Phase 10, messaging).

Java / Spring map

→
In a Spring Boot app, a @RestController method IS the server side of this trip: Spring's embedded web server (Tomcat) accepts the connection, parses the HTTP request, calls your method, and writes the return value as the response. RestClient/WebClient are the client side when your service calls another service.

Code & diagrams

the life of a requestdiagram

One click, six hops. Each arrow is a network trip that takes time and can fail.

Rendering diagram…

OrderController.javajava

The smallest possible server endpoint: Spring turns the HTTP request into a method call.

@RestController
@RequestMapping("/orders")
class OrderController {
  private final OrderRepository orders;
  OrderController(OrderRepository orders) { this.orders = orders; }

  @PostMapping
  ResponseEntity<Order> place(@RequestBody NewOrder req) {
    Order saved = orders.save(new Order(req.itemId(), req.qty()));   // talk to the database
    return ResponseEntity.status(HttpStatus.CREATED).body(saved);    // the response
  }
}

Explain without notes

In your own words, what's the difference between a client and a server? Can one program be both?

Why does every arrow in a system diagram represent a risk?

Practice

Draw the request path for 'user logs in to a shopping site', naming each client, server, and data store involved.

Trade-offs

↔
Synchronous calls are simple to reason about but make the caller wait and fail if the callee fails; asynchronous messaging decouples and absorbs spikes but adds eventual consistency and more moving parts.

Run it in production

You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:

Networking · HTTP on the wire

Methods, status codes, and headers in raw curl -v output.

Networking · What is a network

The full journey of a packet, hands-on.

Completion checklist

I can explain client, server, request, and response with an analogy
I can list the hops of a web request from click to database and back

Back to phase

Command Palette