---
title: "Spring MVC request lifecycle"
chapter: "06"
---

# Spring MVC request lifecycle

Spring MVC uses the Servlet model. It is a strong default for most blocking web
applications.

## Request path

1. The servlet container accepts HTTP.
2. Filters run, including the Spring Security filter chain.
3. `DispatcherServlet` receives the request.
4. A handler mapping finds a controller method.
5. An adapter resolves arguments and invokes the method.
6. The controller calls application services.
7. Return-value handlers and message converters create the response.
8. Exception handlers translate failures.

## Controller boundaries

Controllers translate HTTP into application commands and results. Keep business
rules in application/domain services. Validate input at the boundary with Bean
Validation and use explicit request/response DTOs instead of exposing entities.

## MVC or WebFlux?

Choose MVC for blocking libraries and the ordinary thread-per-request model.
Choose WebFlux when the whole important path is non-blocking and the workload
benefits from many concurrent waiting operations or streaming. Wrapping JDBC
in a reactive controller does not make it non-blocking.

## REST clients

Modern Spring offers `RestClient` for synchronous use and `WebClient` for
reactive use. Configure timeouts, connection pools, observability, error
mapping, retries, and authentication. Do not create a new client per request.

## Feynman check

`DispatcherServlet` is the reception desk. It finds the right controller,
converts the envelope into Java data, and converts the answer back into HTTP.