Reactive Programming — Fundamentals, Backpressure, and When It Helps

Reactive programming is non-blocking, event-driven data flow with explicit backpressure. Instead of one thread per request blocking on I/O, a small event loop handles thousands of concurrent operations via callbacks.

Three core ideas

• Non-blocking I/O — threads don't wait; callback on response
• Async composition — operators chain declaratively (map, flatMap, zip, filter)
• Backpressure — consumers tell producers how much they can handle

Java ecosystem

• Reactive Streams standard — java.util.concurrent.Flow
• Project Reactor (Spring) — Mono for 0..1, Flux for 0..N
• RxJava — Observable, Single, Flowable, Completable, Maybe
• Spring WebFlux on Reactor Netty
• R2DBC reactive DB drivers; Spring Data Reactive for MongoDB, Redis, Cassandra
• RSocket for reactive RPC

`Mono` and `Flux` are recipes, not values

• Cold by default; nothing runs until subscribe
• Contrast CompletableFuture which starts immediately

Backpressure differentiator

• Signals — onSubscribe, request(n), onNext, onComplete, onError
• Reactor strategies — onBackpressureBuffer/Drop/Latest/Error
• flatMap(fn, N) concurrency parameter is your throttle
• Hot vs cold publishers — late subscribers miss hot events

Reactor in practice

• flatMap for async; Mono.zip for parallel composition
• Error handling — onStatus, timeout, retryWhen with backoff, onErrorResume
• Reactor Context is the reactive ThreadLocal
• Wrap blocking calls — Mono.fromCallable(...).subscribeOn(Schedulers.boundedElastic())

When reactive helps

• Thousands of concurrent slow I/O
• Streaming — SSE, WebSocket, chunked HTTP, Kafka
• Reactive downstream all the way
• Memory-constrained environments

When reactive does NOT help

• CPU-bound workload
• Blocking dependency (plain JDBC, blocking SDK)
• Team without reactive experience
• Service already healthy on thread-per-request

Common mistakes

• .block() in reactive code — deadlocks or stalls
• Ignoring backpressure — memory explosion
• Blocking without subscribeOn — event-loop stall
• Loss of MDC / tracing — use Context Propagation
• Forgetting to subscribe — code does nothing

Project Loom changes the calculus (JDK 21+)

• Virtual threads — 10K-100K cheap threads per JVM
• Tomcat on virtual threads handles 10K+ concurrent with simple blocking code
• For "scale the blocking code" problems, virtual threads often win

2026 recommendation

• Default — Spring MVC + virtual threads
• WebFlux when streaming or reactive-all-the-way is a real requirement
• Don't mix blocking and reactive in one service

Strategic answer

• Reactive is about non-blocking, composition, and backpressure
• Not a universal scaling magic bullet
• Great for streaming and truly async pipelines
• Virtual threads cover the "just scale my blocking code" case in 2026
• Pick reactive when streaming or reactive-all-the-way genuinely fits