Flow API vs Reactor vs RxJava?

• Flow API – the lowest common denominator: four interfaces, no operators, no runtime.
• Reactor – Flux (0..N items) and Mono (0..1 item) with a rich operator set, used by Spring WebFlux.
• RxJava – Flowable (backpressured) and Observable (no backpressure) with operators and schedulers.
• CompletableFuture – models a single asynchronous value with composition (thenApply, thenCompose, thenCombine).
• Virtual threads (Java 21) – lightweight threads that make blocking code scale cheaply, removing much of the concurrency motivation for reactive.

How do Flow API, Reactor, and RxJava relate?

All three implement the same Reactive Streams specification, so they interoperate. Reactor's JdkFlowAdapter.flowPublisherToFlux(jdkPublisher) turns a JDK Flow.Publisher into a Reactor Flux. RxJava's Flowable implements the Publisher interface directly.

Why use Reactor or RxJava instead of raw Flow?

Raw Flow has no operators. Reactor gives declarative operators that preserve backpressure automatically.

Flux.from(jdkPublisher)
    .map(txn -> enrich(txn))
    .filter(txn -> txn.getAmount().compareTo(LIMIT) > 0)
    .flatMap(txn -> scoreAsync(txn), 4)
    .retryWhen(Retry.backoff(3, Duration.ofMillis(100)))
    .subscribe(txn -> log.info("Scored: {}", txn));

When do you choose CompletableFuture?

CompletableFuture represents one future value. Use it for a single result or a fixed set of parallel calls.

package com.bank.service;

import java.math.BigDecimal;
import java.util.concurrent.CompletableFuture;

public class DashboardService {

    public CompletableFuture<Dashboard> loadDashboard(String accountId) {
        var balanceFuture = CompletableFuture.supplyAsync(
            () -> accountRepo.getBalance(accountId));
        var statementFuture = CompletableFuture.supplyAsync(
            () -> statementRepo.getLatest(accountId));

        return balanceFuture.thenCombine(statementFuture,
            (balance, statement) -> new Dashboard(balance, statement));
    }
}

When do virtual threads make reactive unnecessary?

Virtual threads let you write ordinary blocking code that scales. Blocking a virtual thread parks it cheaply instead of pinning an OS thread.

try (var executor = java.util.concurrent.Executors.newVirtualThreadPerTaskExecutor()) {
    for (String accountId : allAccounts) {
        executor.submit(() -> {
            var account = accountRepo.findById(accountId);  // blocking, but cheap
            var score = fraudClient.score(account);         // blocking, but cheap
            return process(account, score);
        });
    }
}

How do you decide between reactive, CompletableFuture, and virtual threads?

| Scenario | Tool | Reason |
|----------|------|--------|
| Continuous stream with backpressure | Reactor / RxJava | Need operators and demand control |
| Single async result | CompletableFuture | One value, simple composition |
| Fan-out a few parallel calls | CompletableFuture | thenCombine joins results |
| High-concurrency blocking I/O | Virtual threads | Blocking code that scales |
| SSE, WebSocket, Kafka pipeline | Reactor | True streaming semantics |

What are the trade-offs of reactive code?

Reactive code is harder to debug because stack traces are fragmented, and you must avoid blocking calls inside the pipeline. Virtual threads remove the debugging pain by keeping simple, stack-trace-friendly blocking code.

What are common mistakes?

The wrong approach is using reactive just for thread efficiency when virtual threads are available.

// WRONG: reactive only for thread savings, not for streaming
Mono.fromCallable(() -> accountRepo.findById("SAV2001"))
    .subscribeOn(Schedulers.boundedElastic())
    .block();  // defeats the purpose

The correct approach uses virtual threads for simple request-per-task.

// CORRECT: blocking code on virtual thread
var account = accountRepo.findById("SAV2001");  // simple, debuggable

What are common interview follow-up questions?

• Can you mix reactive and virtual threads in the same application?
• How does Spring WebFlux relate to Reactor?
• When would virtual threads NOT help?