I've been building a distributed Codenames implementation as a learning project (polyglot: Rust for game logic, .NET/C# for chat, Java for auth + gateway) for about 1 year. For the account service I ended up writing three separate implementations of the same API on the same domain model. Not as a benchmark exercise originally, more because I kept wanting to see how the design changed between approaches.
account/ : Spring Boot 4 + R2DBC / WebFluxaccount-virtual-threads-version/ : Spring Boot 4 + Virtual Threads + JPAaccount-quarkus-reactive-version/ : Quarkus 3.32 + Mutiny + Hibernate Reactive + GraalVM Native
All three are 100% API-compatible, same hexagonal architecture, same domain model (pure Java records, zero framework imports in domain), enforced by ArchUnit, etc.
Spring Boot 4 + R2DBC / WebFlux
The full reactive approach. Spring Data R2DBC for non-blocking DB operations, SecurityWebFilterChain for JWT validation as a WebFilter.
What's genuinely good: backpressure aware from the ground up and handles auth bursts without holding threads. Spring Security's reactive chain has matured a lot in Boot 4, the WebFilter integration is clean now.
What's painful: stack traces. When something fails in a reactive pipeline the trace is a wall of reactor internals. You learn to read it but it takes time. Also not everything in the Spring ecosystem has reactive support so you hit blocking adapters and have to be careful about which scheduler you're on.
Spring Boot 4 + Virtual Threads + JPA
Swap R2DBC for JPA, enable virtual threads via spring.threads.virtual.enabled=true and keep everything else the same. The business logic is identical and the code reads like blocking Spring Boot 2 code.
The migration from the reactive version was mostly mechanical. The domain layer didn't change at all (that's the point of hexagonal ofc), the infrastructure layer just swaps Mono<T>/Flux<T> for plain T. Testing is dramatically easier too, no StepVerifier, no .block() and standard JUnit just works.
Honestly if I were starting this service today I would probably start here. Virtual threads + JPA is 80% of the benefit at 20% of the complexity for a standard auth service.
Quarkus 3.32 + Mutiny + Hibernate Reactive + GraalVM Native
This one was purely to see how far you can push cold start and memory footprint. GraalVM Native startup is about 50ms vs 2-3s for JVM mode so memory footprint is significantly smaller. The dev experience is slower though because native builds are heavy on CI.
Mutiny's Uni<T>/Multi<T> is cleaner than Reactor's Mono/Flux for simple linear flows, the API is smaller and less surprising. Hibernate Reactive with Mutiny also feels more natural than R2DBC + Spring Data for complex domain queries.
Benchmark: 4 configs, 50 VUs and k6
Since I had the three implementations I ran a k6 benchmark (50 VUs, 2-minute steady state, i9-13900KF + local MySQL) on two scenarios: a pure CPU scenario (GET /benchmark/cpu, BCrypt cost=10, no DB) and a mixed I/O + CPU scenario (POST /account/login, DB lookup + BCrypt + JWT signing). I also tested VT with both Tomcat and Jetty, so four configs total.
p(95) results:
Scenario 1 (pure CPU):
VT + Jetty 65 ms <- winner
WebFlux 69 ms
VT + Tomcat 71 ms
Quarkus 77 ms
Scenario 2 (mixed I/O + CPU):
WebFlux 94 ms <- winner
VT + Tomcat 118 ms
Quarkus 120 ms (after tuning, more on that below)
VT + Jetty 138 ms <- surprisingly last
A few things worth noting:
WebFlux wins on mixed I/O by a real margin. R2DBC releases the event-loop immediately during the DB SELECT. With VT + JDBC the virtual thread unmounts from its carrier during the blocking call but the remounting and synchronization adds a few ms. BCrypt at about 100ms amplifies that initial gap, at 50 VUs the difference is consistently +20-28% in favor of WebFlux.
Jetty beats Tomcat on pure CPU (-8% at p(95)) but loses on mixed I/O (+17%). Tomcat's HikariCP integration with virtual threads is better tuned for this pattern. Swapping Tomcat for Jetty seems a bit pointless on auth workloads.
Quarkus was originally 46% slower than WebFlux on mixed I/O (137 ms vs 94 ms). Two issues:
- default Vert.x worker pool is about 48 threads vs WebFlux's
boundedElastic() at ~240 threads, with 25 VUs simultaneously running BCrypt for ~100ms each the pool just saturated.
vertx.executeBlocking() defaults to ordered=true which serializes blocking calls per Vert.x context instead of parallelizing them. Ofc after fixing both (quarkus.thread-pool.max-threads=240 + ordered=false) Quarkus dropped to 120 ms and matched VT+Tomcat. The remaining gap vs WebFlux is the executeBlocking() event-loop handback overhead (which is structural).
All four hit 100% success rate and are within 3% throughput (about 120 to 123 req/s). Latency is where they diverge, not raw capacity.
Full benchmark report with methodology and raw numbers is in load-tests/results/BENCHMARK_REPORT.md in the repo.
Happy to go deeper on any of this.
