Concurrency in real systems question 130 of 180 senior
What does a reactive framework buy you over threads, and what does it cost?
- Faster CPU-bound code
- Correct: High concurrency on few threads through non-blocking I/O, at the cost of a programming model where one blocking call poisons the event loop
- Automatic parallelism with no code change
- Thread safety by construction
Reactor, RxJava and the rest run your pipeline on a small event loop, typically one thread per core. Because no thread ever blocks, tens of thousands of in-flight requests cost almost nothing, and backpressure is part of the protocol rather than something you bolt on.
The costs are real and worth stating plainly: stack traces that do not describe your control flow,
debuggers that cannot step through it, ThreadLocal that does not work (hence the Context), and the
absolute rule that no blocking call may appear anywhere on the loop. One JDBC driver in a reactive
chain takes down throughput for everything sharing that loop, which is why BlockHound exists.
The 2026 answer to "would you start a new service reactive": usually no, if the reason was only thread cost, because virtual threads deliver most of that with ordinary code. Yes, if you want streaming semantics, backpressure across a pipeline, or the operator vocabulary for composing event streams.
Quiz yourself on Concurrency in real systems Suggest a correction