How does the request lifecycle work in Spring Boot?

Question

IT Interview Practice · Accepted Answer

In Spring Boot (Spring MVC), a request passes through the **servlet container**, a chain of **Filters**, the central **`DispatcherServlet`**, then **interceptors** and your **`@Controller`**, and the return value is converted into the HTTP response.

## The stages

```
Servlet container (Tomcat)
   ▼
Filter chain  ── (CharacterEncoding, Security, CORS, ...)
   ▼
DispatcherServlet  ── the front controller
   ▼
HandlerMapping  ── find the @Controller method
   ▼
HandlerInterceptor.preHandle
   ▼
Argument resolvers  ── bind @RequestBody / @PathVariable / @RequestParam
   ▼
Controller method  ── your logic → returns object or ResponseEntity
   ▼
HandlerInterceptor.postHandle
   ▼
HttpMessageConverter / ViewResolver  ── serialize to JSON or render view
   ▼
HandlerInterceptor.afterCompletion → Response ──▶ client
```

1. **Container + filters** — Tomcat hands the request to the `Filter` chain. Filters (including Spring Security) are the outermost layer and can block or wrap the request before MVC sees it.
2. **DispatcherServlet** — the front controller that orchestrates everything below.
3. **HandlerMapping** — resolves which controller method handles the URL + method.
4. **`preHandle`** — `HandlerInterceptor`s run before the controller (auth checks, logging, timing); returning `false` stops the request.
5. **Argument resolution** — `@PathVariable`, `@RequestParam`, and `@RequestBody` (via `HttpMessageConverter`) are bound and validated.
6. **Controller** — your `@RestController` method runs the business logic and returns an object or `ResponseEntity`.
7. **`postHandle`**, then the return value is serialized by an `HttpMessageConverter` (JSON via Jackson) or a view is rendered by a `ViewResolver`.
8. **`afterCompletion`** runs after the response is committed; `@ExceptionHandler`/`@ControllerAdvice` handle exceptions along the way.

```java
// 4/7/8. interceptor
public class TimingInterceptor implements HandlerInterceptor {
    public boolean preHandle(HttpServletRequest req, HttpServletResponse res, Object h) {
        req.setAttribute("started", System.nanoTime());
        return true;                       // false = short-circuit
    }
}

// 6. controller
@RestController
class ItemController {
    @GetMapping("/items/{id}")            // 3. mapping
    ResponseEntity<Item> show(@PathVariable Long id) {  // 5. argument resolution
        return ResponseEntity.ok(service.find(id));      // 7. serialized to JSON
    }
}
```

## Why it matters

Spring's lifecycle has two distinct extension layers that interviewers love to probe: **Filters** (servlet-level, outermost — where Spring Security lives) and **Interceptors** (Spring MVC-level, around the controller). Knowing the order — filters, DispatcherServlet, mapping, interceptor `preHandle`, argument binding, controller, message conversion, `afterCompletion` — tells you where to put authentication vs. logging, why a Security filter rejects a request before any interceptor or controller runs, and how `@ControllerAdvice` centralizes exception handling across the whole flow.

The stages

Why it matters

Related questions