WebFlux vs MVC Stack Choice — Thread-per-Request vs Event Loop
Fast recall
Quick revision
Core answer
Whether the candidate makes a deliberate stack choice — including the impact of virtual threads on the historical reactive vs blocking debate
Defaulting to WebFlux 'for performance' without measuring; ignoring debugging and library compatibility costs
Discuss event-loop fragility under blocking calls, virtual-thread pinning trade-offs, debugging differences, and when to migrate between stacks
Interview-ready guide
Interview answer
Spring offers three real options in 2026, and the default has shifted with virtual threads.
Spring MVC classic
- Servlet-based on Tomcat / Jetty / Undertow
- Thread-per-request blocking; ~200 threads per instance
- JDBC, JPA,
RestTemplate, normal stack traces, mature tooling
Spring WebFlux reactive
- Netty-based non-blocking; few event-loop threads handle thousands of connections
- Returns
Mono/Flux; Reactor operators compose WebClient, R2DBC, reactive Mongo / Redis- Explicit backpressure; native streaming (SSE, WebSocket); RSocket
Spring MVC + Virtual Threads (Boot 3.2+, JDK 21)
- Regular MVC servlet stack with
spring.threads.virtual.enabled=true - Each request runs on a virtual thread; blocking I/O parks without blocking the carrier
- Code stays plain blocking Java;
JdbcTemplate.queryjust works; stack traces normal
The shift
- Virtual threads let blocking code reach reactive-like concurrency
- For most services in 2026, MVC + virtual threads is the right default
- WebFlux earns its place for specific reasons — streaming, RSocket, backpressure, reactive-all-the-way — not as a universal scaling answer
Decision framework
- Streaming or reactive-all-the-way → WebFlux
- Everything else on JDK 21+ → MVC + virtual threads
- Older JDK or moderate scale → classic MVC
Pitfalls
- Choosing WebFlux "for performance" without measuring
- Mixing WebFlux with blocking JDBC without
boundedElastic - Staying on WebFlux when team velocity is suffering
- Not upgrading to virtual threads when migration is trivial
Performance reality
- WebFlux slightly edges MVC + virtual threads on extreme concurrency (50K+ connections)
- MVC + virtual threads wins on debugging, velocity, library compatibility
- Gap usually 10-20%, not orders of magnitude
Strategic answer
- The reactive narrative has shifted
- Virtual threads cover the common case in 2026
- Reactive earns its place for streaming and explicit backpressure — not universally
- Pick deliberately, not by trend
- Migration MVC → MVC + virtual threads is one line of config; migration MVC → WebFlux is large; migration WebFlux → MVC + virtual threads is increasingly common
WebFlux vs MVC Stack Choice — Thread-per-Request vs Event Loop
Direct Answer
Spring MVC is the classic blocking, thread-per-request stack on Tomcat / Jetty / Undertow — simple, mature, JDBC-friendly. Spring WebFlux is the event-loop stack on Netty — handful of threads serve thousands of in-flight calls; native streaming (SSE / WebSocket) and explicit backpressure. The choice in 2026 is between three stacks: classic MVC (older code), MVC + virtual threads (default for new services), and WebFlux (streaming, reactive-all-the-way). Pick WebFlux when streaming, RSocket, or true reactive composition is the requirement; pick MVC + virtual threads for everything else. The deciding factor is rarely raw throughput — it's whether your downstream stack is reactive end-to-end and whether your team can absorb the debugging cost.
Common Mistakes & Pitfalls
Defaulting to WebFlux 'for performance' without measuring; ignoring debugging and library compatibility costs
Check your understanding
Answer these without looking back at the article.
- What is virtual thread pinning and how do you detect and fix it?
- Walk through migrating a blocking MVC service to virtual threads
- When is WebFlux genuinely better than MVC + virtual threads?
- How do you decide DB connection pool size with virtual threads?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.