Front Controller Pattern

Why it matters in enterprise Java

In an e-commerce system, checkout, account, order history, and admin routes all need shared request concerns. A central entry point keeps that policy consistent before individual handlers take over.

Intent, problem, and solution

How the collaboration works

• Client sends all web requests to one central endpoint.
• The front controller resolves handler selection and shared policies.
• Specialized handlers or controllers perform the specific use case work.
• Rendering or API serialization happens after delegation.

Java example in the Order Management domain

package org.javaomnibus.ecommerce.web;

import jakarta.servlet.ServletException;
import jakarta.servlet.annotation.WebServlet;
import jakarta.servlet.http.HttpServlet;
import jakarta.servlet.http.HttpServletRequest;
import jakarta.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.util.Map;

@WebServlet("/*")
public final class CommerceFrontController extends HttpServlet {
    private final Map<String, RequestHandler> handlers = Map.of(
        "/orders", new OrderHistoryHandler(),
        "/checkout", new CheckoutHandler()
    );

    @Override
    protected void service(HttpServletRequest request, HttpServletResponse response)
        throws ServletException, IOException {
        String path = request.getRequestURI();
        RequestHandler handler = handlers.get(path);
        if (handler == null) {
            response.sendError(HttpServletResponse.SC_NOT_FOUND);
            return;
        }
        request.setAttribute("correlationId", java.util.UUID.randomUUID().toString());
        handler.handle(request, response);
    }
}

Step by step

1. All requests arrive through one servlet entry point.
2. Handler resolution happens centrally instead of being repeated in multiple places.
3. Shared metadata such as correlation IDs can be attached once.
4. Concrete handlers stay focused on the specific use case.

Where this pattern shows up

• Spring MVC dispatcher flows
• Central API gateways inside monoliths
• Server-rendered applications with shared request rules

Cases where another shape is better

• Tiny applications where one or two endpoints do not justify extra routing indirection
• Systems where a framework already provides a well-structured central dispatcher

Trade-offs and design pressure

• A front controller can become a giant switch statement if handler dispatch stays too manual.
• Over-centralization can make debugging harder if the entry layer owns too much behavior.

How this differs from nearby patterns

Front Controller is about one central entry point. Intercepting Filter is about a reusable processing pipeline before or around that entry point.

Mistakes to avoid

• Putting business orchestration directly into the front controller
• Letting the front controller grow into a god object for the whole web layer
• Using it as a place for every special case instead of delegating cleanly

Related concepts