When building applications with Spring MVC, everything may look simple from the outside - a HTTP request goes in and a response comes out. But beneath this simplicity lies a beautifully structured processing pipeline that every backend engineer should understand correctly. I believe this understanding helps an engineer debug the system, and knowing these concepts also enhances their system design mindset.

1. The Journey Begins: Client → Server

The lifecycle starts when a client, typically a browser or mobile app sends a HTTP request.

1.1 Proxy / Load Balancer

Before the application even sees the request, it could route through a proxy or load balancer. It helps to:

• decide which server instance should receive the request

• distribute load efficiently and

• improve reliability

1.2 Servlet Container

Once forwarded, the request reaches to a Servlet Container (Tomcat, Jetty, Undertow, etc.). This container:

• implements the Java Servlet specification

• understands how to manage servlets

Most importantly, the Servlet Container has no idea what Spring is or how Spring MVC works. It only unserstands HttpServletRequest and HttpServletResponse.

1.3 Filter Chain

The first processing stage inside the container is the Filter Chain. Filters handle cross-cutting concerns:

• logging

• authentication

• CORS checking

• rate limiting, etc.

After filters finish, the request is handed over to the component that drives the entire Spring MVC engine, the DispatcherServlet.

---

2. DispatcherServlet: Spring MVC Orchestrator

DispatcherServlet serves as the Front Controller in Spring MVC.

Every request eventually reaches this servlet, and all subsequent processing - from identifying controllers to deciding how the response should be rendered is orchestrated from here.

2.1 Why DispatcherServlet exists?

Because of a fundamental technical reason.

Layer 01:

The Servlet Container understands Servlets, but not Spring.

Layer 02:

Spring, on the other hand:

• manages beans

• provides dependency injection

• configures controllers

• manages handler mappings

• contains message converters and view resolvers

The bridge:

DispatcherServlet acts as a bridge between these two Layers.

It knows how to:

• Receive the request from the container

• Talk to Spring application context for request mappings

• Delegate business logic execution

• Manage the final response

Without this bridge, Spring MVC simply couldn’t function.

---

3. HandlerMapping: Choosing the Correct Controller

Once the DispatcherServlet receives the request, it asks: Which controller method should handle this request?

This decision is taken by the HandlerMapping mechanism.

HandlerMapping evaluates:

• URL patterns

• HTTP methods (GET/POST/etc.)

• Consumes/produces rules (JSON/XML)

In simpler terms, HandlerMapping selects the appropriate controller method for the incoming request.

---

4. HandlerAdapter: The Adapter Design Pattern in Spring MVC

Even after finding the correct controller, the DispatcherServlet cannot directly invoke it. Why?

Because Spring supports multiple handler types:

• @Controller methods

• @RestController

• HttpRequestHandler

• Custom handler styles

If the DispatcherServlet depended on specific handler implementations, Spring MVC would lose flexibility.

4.1 The Solution: HandlerAdapter

Spring applies the Adapter Design Pattern here.

A HandlerAdapter knows how to execute a given handler, regardless of its type.

Role of HandlerAdapter:

Given any handler, I understand exactly how to invoke it and obtain a result.

This abstraction layer is what keeps Spring MVC extensible and clean.

---

5. Controller → Service → Repository → Database

There's not much to say about this layer. Developers mostly spent there time to work on it, so we all understand how it functions.

In the final step, the controller sends a result (either data or a view name) back to the DispatcherServlet.

---

6. Response Preparation

DispatcherServlet now decides which output path to follow.

a. HTML Response via ViewResolver

If the controller returns a view name, Spring uses ViewResolver to:

• find the correct template

• render it into HTML

• prepare the final page

b. JSON/XML Response via MessageConverter

If the controller returns data (e.g. using @ResponseBody or @RestController), Spring’s MessageConverter serializes the object into JSON/XML.

Both cases, a final response body is produced.

---

7. Returning the Response: Server → Client

Finally,

• DispatcherServlet writes the response to HttpServletResponse

• Post filter execution may happen in filter chain

• The Servlet Container sends the HTTP response back

• The Load Balancer forwards it to the client

And with that, the request-response lifecycle completes! 🎉🎉🎉

---

The full diagram

---

Thanks for reading! ❤️