Spring WebFlux Fundamentals

Spring WebFlux is the reactive-stack web framework in the Spring ecosystem — a non-blocking, event-loop alternative to Spring MVC, built on Project Reactor's Mono and Flux and running on a few event-loop threads. It exists because the thread-per-request model of Spring MVC sets a ceiling on concurrency: each blocked request holds a thread, threads are expensive, and at high concurrency — tens of thousands of connections, streaming, backpressure-heavy workloads — blocking I/O becomes the bottleneck. WebFlux's event-loop model handles far more concurrent requests on far fewer threads by never blocking them. The mental model I stress is that controllers return Mono for zero-or-one results and Flux for zero-to-many, and backpressure lets a slow consumer control a fast producer. The golden rule is the one that bites people: if any step blocks — a Thread.sleep, a JDBC call — the few event-loop threads stall and every client waits, so blocking work has to go on a separate scheduler or be replaced with a reactive client. The honest trade-off is scalability versus complexity: WebFlux is much harder to write and debug because it's async and declarative with no linear stack trace, so I choose it only for the workloads that justify it — high concurrency, streaming, backpressure — and keep Spring MVC for typical CRUD with blocking JDBC.