When should you choose WebFlux over Spring MVC in a Spring Framework 7 application?

WebFlux earns its complexity when an application is genuinely I/O-bound at high concurrency with a reactive-native downstream stack - for example, a gateway service fanning out to dozens of other services concurrently, a service using R2DBC or reactive MongoDB drivers end to end, or one serving long-lived streaming connections like Server-Sent Events where non-blocking backpressure actually matters.

Historically, the other strong argument for WebFlux was thread efficiency: a blocking MVC application ties up one platform thread per in-flight request, capping concurrency at the thread pool size, while WebFlux's event-loop model handles far more concurrent connections with a small, fixed number of threads. Spring Framework 7's virtual thread support changes that calculus significantly - enabling spring.threads.virtual.enabled=true lets a traditional, imperative Spring MVC application handle massive concurrent blocking I/O cheaply too, without adopting reactive programming at all.

That narrows WebFlux's practical advantage to cases where the whole stack is already reactive (blocking JDBC calls inside a WebFlux pipeline are an anti-pattern that defeats the model), or where the streaming/backpressure semantics of Flux genuinely fit the problem - not simply "high concurrency," which virtual threads now address from the MVC side.