Spring Boot ships with two distinct web stacks: Spring MVC, built on the blocking Servlet API, and Spring WebFlux, built on Project Reactor’s non-blocking event loop. Both are mature, both are production-ready, and both handle HTTP requests — but they make fundamentally different trade-offs. Picking the wrong one for your workload creates either unnecessary complexity or a performance ceiling you’ll eventually hit.
This post is a practical decision guide, not a reactive programming primer. The aim is to help you choose deliberately rather than by default.
How They Differ: Threading Models
Spring MVC uses one thread per request. A request arrives, a thread from the pool picks it up, and that thread is occupied until the response is sent. If your handler calls a database or another service, the thread blocks and waits. Tomcat’s default thread pool handles up to 200 concurrent requests out of the box — under 200 concurrent in-flight requests, you’re fine. Beyond that, threads queue.
Spring WebFlux uses a small, fixed event-loop thread pool — typically one thread per CPU core. Requests are handled asynchronously: when I/O is initiated, the event-loop thread is freed to handle other requests. When the I/O completes, a callback resumes processing. Reactor’s Mono and Flux types represent deferred results that compose these callbacks.
The implication: under high concurrency with significant I/O wait, WebFlux can serve far more requests with far fewer threads. Under low concurrency, or when most processing is CPU-bound rather than I/O-bound, WebFlux offers no throughput advantage and adds meaningful complexity.
When WebFlux Actually Helps
WebFlux earns its keep in specific scenarios:
High-concurrency I/O-bound services. An API gateway, a streaming service, or a real-time data feed handler that maintains thousands of concurrent connections. WebFlux can handle these with a handful of threads; MVC would need a thread pool large enough to match.
Server-Sent Events and WebSockets. Streaming responses to many clients simultaneously is natural in WebFlux (Flux<ServerSentEvent>). In MVC, keeping a thread open per connection becomes expensive fast.
Service-to-service fan-out. If your handler calls three external services and can make all three calls simultaneously, Mono.zip() composes the parallel calls cleanly without blocking threads while waiting for each to return.
Systems already built reactively. If your data layer uses R2DBC or a reactive MongoDB driver, building a reactive controller on top is consistent. Mixing reactive data access with blocking MVC controllers requires calling .block(), which defeats the purpose.
When MVC Is the Right Choice
Most Spring Boot microservices should use MVC. The reasons:
Typical microservice workloads are not concurrency-limited. A service handling 100–1,000 requests per second with sub-100ms database calls rarely saturates a 200-thread MVC pool. The performance difference between MVC and WebFlux at this scale is unmeasurable.
The reactive programming model has a high cognitive cost. Debugging a reactive call chain is harder than stepping through a sequential stack trace. Error propagation through Mono.flatMap().onErrorResume() is less obvious than a try/catch. Teams who are not already fluent in reactive programming pay this cost on every feature, every code review, and every production incident.
JDBC is blocking and cannot be used in a WebFlux event loop. If your service uses Spring Data JPA, you cannot use WebFlux correctly without either blocking the event loop (wrong) or wrapping every JDBC call in a subscribeOn(Schedulers.boundedElastic()) (functional but awkward, and it partially cancels the benefit of WebFlux).
Spring Virtual Threads (Java 21+) change the calculus. With spring.threads.virtual.enabled=true, Spring MVC runs each request on a virtual thread. Virtual threads are lightweight and do not block carrier threads during I/O — they offer reactive-level concurrency without the reactive programming model. For greenfield services on Java 21+, virtual threads with Spring MVC is often the better path than WebFlux.
Side-by-Side
A simple controller that fetches data from an external API:
Spring MVC:
@RestController
@RequestMapping("/markets")
public class MarketController {
private final MarketService marketService;
@GetMapping("/{id}")
public MarketDetail getMarket(@PathVariable String id) {
return marketService.fetchMarket(id); // blocks until response
}
}
Spring WebFlux:
@RestController
@RequestMapping("/markets")
public class MarketController {
private final MarketService marketService;
@GetMapping("/{id}")
public Mono<MarketDetail> getMarket(@PathVariable String id) {
return marketService.fetchMarket(id); // returns a deferred result
}
}
The WebFlux version looks similar. The complexity appears in the service layer, the error handling, and the test setup. Every call becomes a Mono or Flux, every transformation a flatMap, every error path an onErrorResume. That cognitive overhead is the price you pay for the concurrency model.
Parallel Calls in Each Stack
Where WebFlux shows its clearest advantage is fan-out. Calling two services simultaneously:
MVC with virtual threads (Java 21):
public MarketSummary getMarketSummary(String marketId) {
try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
var marketFuture = scope.fork(() -> marketApi.getMarket(marketId));
var priceFuture = scope.fork(() -> priceApi.getPrices(marketId));
scope.join().throwIfFailed();
return new MarketSummary(marketFuture.get(), priceFuture.get());
}
}
WebFlux:
public Mono<MarketSummary> getMarketSummary(String marketId) {
return Mono.zip(
marketApi.getMarket(marketId),
priceApi.getPrices(marketId),
MarketSummary::new
);
}
Both achieve concurrency. Structured concurrency with virtual threads is arguably more readable for Java developers who are not already fluent in reactive.
The Decision Framework
Start with these questions:
- Are you on Java 21+? If yes, enable virtual threads and use Spring MVC. You get the concurrency of reactive without the model.
- Do you need persistent streaming connections to many clients? WebFlux handles this well; MVC does not.
- Is your data layer reactive (R2DBC, reactive MongoDB)? Then WebFlux is consistent. Using reactive drivers in an MVC service requires
.block()calls. - Is your team fluent in reactive programming? If not, the learning cost is real and ongoing.
- Are you hitting thread pool exhaustion under your current load? If not, MVC is serving you fine.
For the vast majority of Spring Boot microservices — especially data APIs, trading system backends, and integration services with blocking JDBC — Spring MVC with virtual threads is the right choice. WebFlux is the right choice for genuinely high-concurrency, I/O-bound services, streaming endpoints, and teams already operating reactively.
Choose for your workload, not for the pattern’s prestige.
If you’re designing the architecture for a Spring Boot service and want a second opinion on the stack choice, get in touch.
