Spring Cloud Gateway ships both a reactive (WebFlux/Netty) server and a servlet (Spring MVC) server. As an architect, how do you decide which to run, and what does the reactive stack actually buy you?

## Same façade, two engines Spring Cloud Gateway exposes one mental model — **Routes** (a route = id + URI + predicates + filters) — over two server runtimes: - **Server WebFlux (reactive):** the classic gateway, on Spring WebFlux + Project Reactor + **Netty**. Proxying uses reactor-netty's non-blocking `HttpClient`. - **Server MVC (servlet):** a newer variant on the Spring MVC servlet stack (WebMvc.fn), proxying with the blocking `RestClient`. Filters/predicates are written in a blocking style. (These have been renamed/repackaged across Spring Cloud versions, but the two-runtime split is the durable idea.) ## What reactive actually buys you 1. **Connection-concurrency efficiency:** an event loop (~one thread per core) multiplexes thousands of waiting proxied requests. Memory/threads scale with *active* work, not in-flight count. For a fan-out gateway fronting many/slow backends, this is dramatically cheaper than thread-per-request. 2. **End-to-end streaming + backpressure:** bodies flow as `Flux<DataBuffer>`; reactor-netty ties Reactive Streams demand to TCP flow control, so large uploads/downloads and SSE/streaming APIs relay in constant memory and a slow side throttles the fast side. 3. **Long-lived/streaming protocols:** WebSockets, SSE, and many idle-but-open connections are cheap when a connection doesn't pin a thread. ## What it costs 1. **Programming model:** everything is `Mono`/`Flux`; debugging, stack traces, and context propagation are harder. 2. **No-blocking rule:** the event loop must never block. Blocking JDBC/JPA, blocking HTTP clients, blocking auth/crypto SDKs, heavy CPU — all must be replaced (WebClient, R2DBC) or offloaded to `Schedulers.boundedElastic()`. A single accidental block can cause cliff-edge throughput collapse. Guard with BlockHound. 3. **Ecosystem friction:** libraries the team depends on may be blocking-only. ## What MVC buys you 1. **Familiarity & ecosystem:** ordinary blocking code, blocking libraries reused as-is, simpler debugging. 2. **Adequate at moderate concurrency:** with modern hardware and virtual threads (Project Loom on the servlet stack), thread-per-request handles far more concurrency than before, narrowing the reactive advantage for many workloads. 3. **No event-loop footgun:** a blocking call costs one request, not the whole server. ## Decision framework - **Choose reactive when:** very high connection concurrency, large fan-out, slow/long-tail downstreams, streaming/SSE/WebSocket relaying, big body streaming, and the team can commit to a non-blocking codebase. - **Choose MVC when:** moderate concurrency, the filter logic must call blocking libraries you can't replace, the team lacks reactive expertise, or virtual threads already give you the concurrency you need with simpler code. - **Neutral factors:** routing/predicate/filter capabilities are largely equivalent; both integrate with discovery, resilience (circuit breakers), and rate limiting. ## Gotchas at the architecture level - **Don't pick reactive for prestige.** If your gateway logic is inherently blocking (heavy DB lookups per request) and you'll just wrap everything in `boundedElastic`, you've paid the complexity tax and thrown away the benefit — MVC (or reactive with R2DBC) is more honest. - **Virtual threads shift the calculus:** Loom makes blocking-style code scale on the servlet stack, so the historical 'reactive for concurrency' argument is weaker for plain fan-out; reactive's clearest remaining edge is true streaming/backpressure and very-high idle-connection counts. - **Operational parity:** ensure your observability, tracing (context propagation across scheduler hops in reactive), and load-testing reflect the chosen model. ## Bottom line Reactive is the right default for a high-scale, streaming, fan-out edge where you can stay non-blocking. MVC is a legitimate, simpler choice when concurrency is moderate or your logic must block — increasingly viable with virtual threads.