Reactive vs blocking benchmark mistakes?

• Coordinated omission – closed-model generators hide tail latency unevenly; the reactive stack queues internally and looks flatteringly fast.
• Database saturation – both stacks funnel into the same database; if it saturates, you measure the database, not the application model.
• Connection pool sizing – JDBC pools need more connections (thread-per-request); R2DBC pools need fewer (non-blocking multiplexing).
• GC pressure – R2DBC and the reactive pipeline allocate many tiny short-lived objects; an undersized young generation (-Xmn) causes frequent minor collections.
• Fair comparison – hold everything equal except the architecture.

Why does coordinated omission affect reactive and blocking differently?

In a closed-model generator, the reactive stack queues work internally rather than blocking a thread, so under a closed model it absorbs bursts invisibly and reports a flattering p99. The blocking stack's thread exhaustion is more visible. The fix is an open, constant-arrival-rate generator for both.

How does database saturation ruin the comparison?

Both services send SQL to the same database. If load drives it to 100% CPU, both stacks wait on the database and their latencies converge. You are benchmarking PostgreSQL, not the concurrency model.

# Fair isolation: stub the data layer with a fixed-delay fake
public class FakeAccountRepo implements AccountRepository {
    public Account findById(String id) {
        Thread.sleep(5);  // simulate 5 ms DB latency
        return new Account(id, new BigDecimal("100000"));
    }
}

How do you match connection pool sizing?

The blocking stack uses HikariCP. A common formula is pool size = cores x 2 + spindle count. The reactive stack uses R2DBC with a smaller pool because non-blocking I/O multiplexes many requests over few connections.

| Stack | Pool Type | Typical Size | Reason |
|-------|-----------|-------------|--------|
| Blocking (JDBC) | HikariCP | cores x 2 | One connection per thread |
| Reactive (R2DBC) | R2DBC Pool | cores x 1 | Non-blocking multiplexing |

Giving the blocking stack a tiny pool throttles it unfairly. Giving either a huge pool saturates the database.

How does GC pressure punish reactive unfairly?

R2DBC and the reactive pipeline allocate many tiny, short-lived objects per request: operator wrappers, subscriptions, signals, lambda captures, and small buffers. These die young and are cheap to collect if the young generation is large enough.

# WRONG: undersized young generation for reactive
java -Xmn128m -jar reactive-service.jar
# Eden fills constantly, minor GC storms, inflated p99

# CORRECT: generous young generation
java -Xmn1g -jar reactive-service.jar
# Or let G1 size it adaptively
java -XX:+UseG1GC -jar reactive-service.jar

What does a fair benchmark setup look like?

Same open-model generator, same unsaturated dependency, correctly sized pools for each model, and a JVM tuned so neither stack is starved of young-generation space.

What are common mistakes?

The wrong approach uses a closed generator, a saturated database, mismatched pools, and a tiny young generation.

The correct approach holds everything equal except the architecture.

When does blocking beat reactive?

At low concurrency blocking often wins on raw latency because it avoids the reactive overhead. Reactive's advantage is specifically thread efficiency under high concurrency. Quoting a low-concurrency result as proof reactive is slower is misleading.

What are common interview follow-up questions?

• How do you measure allocation rate per request for each stack?
• How do virtual threads change the reactive-vs-blocking comparison?
• What is the minimum concurrency where reactive starts to win?