Client–Server and HTTP Request Lifecycle

What it is

A request lifecycle is the ordered work that begins when a client resolves a host and ends when it receives, interprets, and possibly caches an HTTP response. The application controller is only one stage in that path.

Why it matters

Production failures often sit outside business code. DNS errors, TLS negotiation, proxy timeouts, security filters, exhausted application pools, slow SQL, serialization, and client cancellation can produce similar symptoms unless you know the boundaries.

How it works

1. 1

   Resolve and connect

   DNS maps the host name to an address; TCP creates an ordered byte stream; TLS authenticates the server and protects the connection.

2. 2

   Route and protect

   The reverse proxy terminates or forwards TLS, applies size and timeout policy, and sends the request to a healthy application instance. Servlet filters run before the controller, including Spring Security.

3. 3

   Execute application work

   Spring maps input, validates it, invokes a service, opens the intended transaction, runs parameterized SQL through MyBatis, and serializes the result.

4. 4

   Return and observe

   Status, headers, and body travel back through the proxy. Logs, metrics, and trace context should identify the same request without exposing credentials.

Simple example

GET /v1/tasks/42 HTTP/1.1
Host: api.example.com
Accept: application/json
Traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{"id":42,"title":"Review settlement","status":"OPEN"}

HTTP defines the message semantics. It does not guarantee that the database committed only once; that is an application and data-consistency responsibility.

Backend example

@RestController
@RequestMapping("/v1/tasks")
final class TaskController {
    private final TaskQueryService taskQueryService;

    TaskController(TaskQueryService taskQueryService) {
        this.taskQueryService = taskQueryService;
    }

    @GetMapping("/{id}")
    TaskResponse findById(@PathVariable long id) {
        return taskQueryService.findById(id);
    }
}

Production example

Common mistakes

• Calling the controller the start of the request
• Trusting inbound X-Forwarded-* headers from the public internet
• Logging Authorization or Cookie values
• Using retries without an idempotency and deadline policy
• Treating a client timeout as proof that server-side work rolled back

Best practices

• Use one correlation or trace context across trusted boundaries
• Configure connect, read, write, queue, and database timeouts explicitly
• Return protocol-correct status and media types
• Keep reverse-proxy and application limits aligned
• Measure latency at each boundary, not only end to end

Trade-offs

Interview questions

• What happens after a user enters an HTTPS URL?
• Where do Spring Security filters run relative to a controller?
• Why can a client receive a timeout while the database change still commits?
• What is the difference between a forward proxy and reverse proxy?

Hands-on task

1. 1

   Trace

   Call a local Spring endpoint with curl -v and record DNS, connection, request, response, and timing evidence.

2. 2

   Instrument

   Add a correlation filter and structured request-completion log that excludes credentials and request bodies.

3. 3

   Fail

   Introduce a slow query and compare client, proxy, application, and database timeouts.

Related topics

• REST API Design Fundamentals
• Spring Boot Layered Architecture
• Spring Security Authentication Flow
• Observability and timeout budgets

References

• IETF: RFC 9110 — HTTP Semantics — https://www.rfc-editor.org/rfc/rfc9110
• IETF: RFC 8446 — The Transport Layer Security Protocol Version 1.3 — https://www.rfc-editor.org/rfc/rfc8446
• Spring: Annotated Controllers — https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-controller.html
• NGINX: NGINX Reverse Proxy Guide — https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/