Spring MVC vs. Spring WebFlux
NewBoth show up as 'Spring Boot' on a resume, but they are two different ways of writing a Java web service. Spring MVC handles each request on its own thread and is what most Spring services use. Spring WebFlux is reactive: a few threads juggle many requests, which suits services making lots of slow calls, but the code is harder to write and debug. Java 21's virtual threads give MVC much of the same benefit, which weakens the case for WebFlux in new projects.
How to tell them apart on a resume
Spring MVC
@RestController, Spring Data JPA, Hibernate, Tomcat, ordinary blocking calls: the usual Spring Boot microservice.
Spring WebFlux
Mono, Flux, Project Reactor, R2DBC, WebClient, Netty, reactive streams, backpressure.
The question that settles it
“Were your Spring services written in the usual Spring MVC style, or reactive with WebFlux, Mono and Flux?”
Each term in plain English
- Spring Boot
A layer on top of the Spring Framework that auto-configures most of the setup work, letting developers get a Java backend running with minimal manual wiring.
Ask “Tell me about a time Spring Boot's auto-configuration did something you didn't expect, and how you diagnosed it.”
- Spring WebFlux (Reactive Java)
Spring's reactive way of building web services: instead of one thread waiting on each slow call, a few threads juggle many requests at once, which suits services that make lots of network calls.
Ask “Why did your team choose WebFlux over normal Spring MVC, and was it worth the extra complexity?”
- Virtual Threads (Java 21)
A Java feature, standard since Java 21 (2023), that lets an application run huge numbers of lightweight threads cheaply.
Ask “Have you used virtual threads in production? What changed, and what did you have to watch out for?”
Open the full tool for the other look-alike pairs, role profiles, and the JD decoder.