MVC, WebFlux and virtual threads: choose by constraints
Prerequisites: 01-ecosystem
Which I/O contract fits the execution model?
Goal & mental model verified
MVC supports an imperative request model; WebFlux uses non-blocking composition and reactive backpressure. Mono represents zero-or-one values and Flux a sequence. Virtual threads provide a separate way to scale blocking waits.
[S26] [S13]Worked example · design exercise synthesis
A JPA quote API fits MVC naturally. A streaming aggregator with non-blocking downstream clients may fit WebFlux. Wrapping a blocking JPA call in Mono does not make its I/O non-blocking.
[S26] [S13] [S44]Engineering decision synthesis
Choose based on dependency APIs, concurrency pattern and team expertise. MVC with virtual threads can retain readable blocking code; WebFlux adds composition and scheduling discipline.
[S26] [S13] [S44]Pitfall & diagnosis synthesis
Blocking an event loop can stall unrelated requests. A reactive return type alone does not identify the server stack, and virtual threads do not remove database limits.
[S26] [S13] [S44]Improve & validate synthesis
Prototype the same realistic workload with bounded dependencies. Compare memory, tail latency and failure handling; adopt complexity only for a measured benefit.
[S26] [S13] [S44]Check yourself: Does Mono.just(blockingCall()) defer that call?
No. The argument is evaluated immediately before Mono.just receives it.