Rewriting the Load Test for WebFlux Migration

Migrating the event coupon API from the existing blocking structure (event-api) to a reactive structure (reactive-api) initially showed a 4–4.7x performance improvement in load tests. However, this was an illusion caused by flaws in the measurement environment, not an advantage of the reactive architecture.

The load testing tool and the server shared the same CPU, causing resource contention, and performance degradation due to x86 emulation in an ARM64 environment affected the measurement results. Additionally, the Redis connection validation option (validateConnection=true) in the existing API caused synchronization locks, acting as a major bottleneck that reduced throughput by up to 9.2x.

After isolating the measurement environment with Docker and switching the tool to k6, re-measurement showed that the existing blocking approach recorded higher TPS than the reactive approach at 200+ Vusers. For simple lookup requests close to CPU-bound, the overhead of the reactive pipeline actually led to throughput loss. This confirmed that non-blocking is not a technology that increases absolute speed, but rather a technology for efficiently handling many connections with fewer threads.