Programación reactiva con Spring WebFlux no es para todos los casos. Analizo los escenarios donde realmente brilla.
El caso Ecopagos Bancolombia
En Personal Soft, desarrollamos el sistema de Ecopagos para Bancolombia. El requerimiento: procesar miles de pagos simultáneos con alta concurrencia. Cada transacción involucraba llamadas a múltiples servicios externos (validación, autorización, notificación). Con un enfoque bloqueante clásico, necesitábamos cientos de threads solo para mantener las conexiones abiertas.
¿Cuándo brilla WebFlux?
- ▹ I/O intensivo: Muchas llamadas a servicios externos o bases de datos.
- ▹ Alta concurrencia: Miles de conexiones simultáneas.
- ▹ Streaming: Server-Sent Events, WebSockets, datos en tiempo real.
- ▹ Backpressure: Cuando el productor genera datos más rápido de lo que el consumidor puede procesar.
¿Cuándo NO usarlo?
Si tu servicio es CPU-intensivo (procesamiento de imágenes, cálculos complejos), WebFlux no te da ventaja. Si tu equipo no tiene experiencia con programación reactiva, la curva de aprendizaje puede matar la productividad. Si tu ORMs es JPA/Hibernate (bloqueante), pierdes el beneficio. Para estos casos, un Spring MVC clásico con virtual threads (Java 21) es más pragmático.
Resultado real
Con WebFlux en Ecopagos logramos manejar 10x más concurrencia con la mitad de infraestructura. El throughput pasó de 500 req/s a 5000 req/s con los mismos recursos. Pero fue un cambio que requirió repensar toda la arquitectura, no solo cambiar anotaciones.
