Reactividad en Java: ¿más RAM o más CPU? Event Loop en acción

¿Pensarías que un modelo con más objetos en memoria podría consumir menos RAM en alta carga? Parece contraintuitivo, ¿verdad? Descubre cómo el modelo reactivo en Java logra esta sorprendente hazaña.

Introducción: la lógica que nos engaña

Imagina que estás en un supermercado con solo dos cajeros atendiendo y una fila larga de personas esperando. Cada persona (petición HTTP) ocupa un cajero (hilo), obligando al supermercado a abrir más y más cajas a medida que llegan clientes. A primera vista parece lógico: más personas, más cajas. Aplicado a Java: más requests, más hilos y, por ende, más RAM. Pero ¿qué tal si existiera un sistema donde con solo unas pocas cajas pudiéramos atender miles de personas eficientemente? Eso es justo lo que hace el modelo reactivo.

Modelo tradicional (imperativo clásico con JDBC): la fila interminable

En el modelo tradicional cada petición HTTP genera su propio hilo:

• 1 request → 1 hilo → 1 stack de memoria (512 KB–1 MB por hilo)

• Objetos temporales: DTO, conexiones JDBC, resultsets, loggers, etc.

Ahora visualiza una aplicación con 10.000 usuarios concurrentes:

• 10.000 requests → 10.000 hilos → 5-10 GB solo para stacks

• Heap desbordado con miles de objetos vivos

• Garbage Collector bajo estrés constante

¿Resultado? Escalabilidad limitada, latencias altas y servidores que explotan en cargas elevadas.

Modelo reactivo: el mozo con números mágicos

Imagina ahora un restaurante en el que un mozo reparte números a cada cliente, y solo unos pocos meseros atienden a muchos clientes simultáneamente, yendo y viniendo de forma eficiente. Esta analogía ilustra perfectamente el Event Loop:

• 1 hilo (event loop) → miles de requests

• Pocos hilos compartidos (generalmente 8-16 en Vert.x)

• Estructuras livianas: Uni/Multi con callbacks, ocupando poco heap

¿Cómo interactúan Mutiny y Vert.x?

• Vert.x: Motor asincrónico con un event loop, manejando eventos y llamadas no bloqueantes.

• Mutiny: API fluida y sencilla para encadenar operaciones asincrónicas usando Uni/Multi.

La magia es que aunque tengas más estructuras vivas (callbacks), son tan efímeras y livianas que apenas impactan en la RAM.

Visualiza de nuevo los 10.000 usuarios concurrentes, pero ahora en reactivo:

• 10.000 requests → 8 hilos → ~8 MB para stacks

• RAM y CPU bajo control

• Latencia estable

Comparativa técnica rápida

La bomba de optimización

Lo que parecía un riesgo para la memoria termina siendo una optimización brutal: menos RAM, menos CPU, menos hilos y mayor capacidad de respuesta. Esto no solo suena bien, sino que es el motivo por el que empresas como Netflix, Twitter y LinkedIn adoptan modelos reactivos para sus plataformas de alta concurrencia.

Si desarrollas APIs REST, microservicios o sistemas cloud-native, es momento de darle una oportunidad al modelo reactivo. Y recuerda: aunque tu sistema sea pequeño hoy, estarás preparado para escalar sin miedo mañana.

Conclusión: reaccionar es optimizar

La próxima vez que pienses que lo reactivo es solo para casos extremos, recuerda esto: no es solo reaccionar más rápido, sino gastar menos para hacer más. Escalar sin perder control del CPU, de la RAM ni de la paciencia.

¿Ya estás pensando en implementar un modelo reactivo? Déjame saber tu experiencia en los comentarios!