Grasping Reactive Programming in Java: A Basic Guide with Reactor

Most code you write is pull-based. You have a collection, you ask it for the next item, it hands one over, you ask again — an Iterator, a loop. You're in charge, and the data waits for you. Reactive programming flips that around. The data source, a Publisher, pushes values at a Subscriber as they become available, and the subscriber reacts. Nobody blocks on a call waiting for the next item; values arrive as events. That inversion — from "I pull when I'm ready" to "it pushes when it's ready" — is the whole idea, and everything else follows from it.

Why push, and why it isn't free

The reason to push is concurrency under load. A pull model tends to block: you call for data and your thread sits idle until it arrives. Do that for thousands of simultaneous users and you need thousands of parked threads — the exact expensive problem from the earlier threads posts. A reactive, non-blocking pipeline lets one small pool of threads juggle an enormous number of in-flight operations, because nothing sits blocked waiting on I/O. For an I/O-heavy service — a gateway fanning out to other services, a feed of live updates — that's a real efficiency win.

The problem push creates: backpressure

But pushing introduces a hazard that pulling never had. If the producer emits faster than the consumer can handle, where do the extra items go? Left unbounded, they pile up in memory until the process falls over. This is the problem reactive streams take seriously, and the answer is backpressure: the subscriber tells the publisher how much it can handle — request(n) — and the publisher is obliged to respect it. The consumer sets the pace, and the signal travels upstream. Backpressure is the part that separates a real reactive system from "callbacks with extra steps"; it's flow control built into the protocol itself.

The libraries

You don't build this by hand. In Java the dominant library is Project Reactor, which gives you two types: Flux, a stream of zero-to-many values, and Mono, a stream of zero or one. It's the engine under Spring WebFlux, which is where most Java developers actually meet reactive code. RxJava is the other big one, with its Observable and the backpressure-aware Flowable. They differ in the details but share the model: a pipeline of operators — map, filter, flatMap — that describe how values are transformed as they flow through, written once and applied to every item that arrives.

The honest part: it's a big commitment

Here's where I temper the enthusiasm. Reactive code is genuinely harder to live with. A stack trace no longer maps to your source in a straight line; debugging an asynchronous operator chain is its own skill; and everything the pipeline touches has to be non-blocking too, or the whole benefit collapses — one blocking database call in a reactive flow and you've paid all the complexity cost for none of the gain. It's a whole-of-stack commitment, not a local optimisation you can sprinkle on.

And it's worth knowing the ground has shifted since reactive's peak hype. It rose largely to solve the "blocking wastes threads" problem, and Java's virtual threads now dissolve a big part of that while letting you write ordinary, straightforward blocking-style code. So the honest guidance is narrower than the enthusiasm once was: reach for reactive when you genuinely need its flow-control and streaming semantics — high-throughput, I/O-bound, real-time pipelines where backpressure actually matters. For everything else, the simpler model is now genuinely competitive, and simpler is a feature, not a compromise.