Tenía que implementar un broker para operar en el mercado (no quiero dar muchos detalles por aquello de preservar el anonimato de mi cliente). Una vez superada con éxito la certificación para operar en el mercado, y tras un tiempo razonable en producción, me gustaría compartir las lecciones que he aprendido durante este proyecto a modo de post-mortem (muy) informal.
Para quien no esté familiarizado: un broker exige alta velocidad, cuasi tiempo real y una fiabilidad considerable — aquí están en juego los dineros—. Es, en esencia, una aplicación de misión crítica.
Para implementarlo opté por Spring Boot, WebFlux y Netty (Servidor web 100% reactivo) y es una aplicación 100% reactiva, o casi, porque no todo es reactivo en el universo y hay que integrarse con librerías que no lo son.
Lo que sigue son impresiones personales, no digo que sea cierto :-), son las cosas que he aprendido (y sufrido) personalmente. Decía mi padre que nadie escarmienta en cabeza ajena, pero por si acaso a alguien le resulta de utilidad...
Lo mejor de lo mejor, me he divertido muchísimo. Este proyecto ha hecho que tenga que esforzarme al máximo, tirar de todos mis conocimientos nuevos y antiguos y combinarlos de maneras insospechadas. Pura adrenalina. Máximo esfuerzo. Sientes que hay algo en ese cráneo hueco.
Sin duda, lo más difícil, pensar en reactivo. No es un cambio técnico; es un cambio de paradigma. Más que en algoritmos tienes que pensar en términos de flujos de datos y eventos y como coserlos juntos de manera armoniosa.También tienes que aprender a pensar en funciones, pero en su acepción matemática. Que todo fluya y ocurra de manera natural. Be water my friend. Es difícil, y estoy bastante seguro de que no lo he pillado del todo. Descubres que la programación imperativa es como las viejas novias; cuando estás en dificultades quieres volver con ellas. Pero todos sabemos que esto es un error.
He visto cosas que vosotros, programadores imperativos, no creeríais.
Flujos reactivos bloqueados en el abismo de un Scheduler mal configurado, atrapados en hilos que se desvanecen como ecos en la niebla.
He visto funciones perecer en silencio, abandonadas porque el hilo que las lanzó ya había muerto, dejando solo un rastro de excepciones cripticas en los logs.
He contemplado suscripciones no canceladas, consumiendo memoria como naves en llamas más allá de Orión, desangrando la aplicación en un lento naufragio.
He sentido el peso de flujos que nunca se inician, esperando en vano un evento que no llega, perdidos en el limbo de un Mono olvidado. Todos esos bugs, todos esos errores… se desvanecen como lágrimas en la lluvia.
Es hora de depurar.
Depurar en WebFlux es como resolver un puzle sin pistas y necesitas una atención al detalle casi obsesiva. Te hace mejor programador, te aprieta las meninges.
Me apoyé también en el uso de prometheus y grafana y alguna herramienta de monitorización interna que tuve que crear ad hoc para poder saber qué diablos estaba pasando.
Dos cosas, es necesario un conocimiento profundo de Weblux y es necesario desde el minuto uno.
Y la curva de aprendizaje no es rápida.
Aprender WebFlux es como tomar la pastilla roja en Matrix. Desde el minuto uno, necesitas entender profundamente el mundo reactivo, sus reglas y sus flujos, o te perderás en un laberinto de código que no perdona. No hay vuelta atrás: una vez que entras, el sistema te exige todo. La curva de aprendizaje es como despertar en el desierto de lo real, luchando por comprender un universo donde los hilos no son lo que parecen, los flujos mandan y cada error es una pelea contra un Agente Smith que no da pistas. Pero cuando lo dominas, es como aprender a doblar la cuchara: el código fluye, y tú con él.
Es la única manera. Suponer es más fácil que saber, pero aquí no funciona. Tienes que saber acerca de cada operador que usas, por qué usas ese operador y no otro parecido y que implicaciones tiene.
Suponer es un pecado mortal aquí, como intentar descifrar un manuscrito prohibido con meras conjeturas: te llevará al desastre, a flujos rotos y errores que arden como herejes. Cada operador es un tomo antiguo que debes conocer a fondo: ¿Por qué usas flatMap y no map? ¿Qué secretos oculta concatMap? ¿Qué castigos trae un Scheduler mal invocado? Debes comprender cada implicación, cada sutileza, como Guillermo de Baskerville descifrando los signos del monasterio. Solo con disciplina y conocimiento profundo puedes iluminar el código.¡Penitenciágite! Arrepiéntete de las suposiciones y abraza el estudio.
Por ejemplo, yo SUPUSE que Netty tendría un pool de hilos separado para hacer sus cosas de HTTP. Ahora SÉ que no es así.
El rendimiento de WebFlux es como pilotar el Interceptor V8 a toda velocidad por los desiertos de Mad Max. Es pura, llana y simplemente espectacular: cada flujo reactivo ruge como un motor afinado, llevando cientos de mensajes por segundo sin pestañear. Pero no solo es rápido; es robusto como una fortaleza blindada. Las políticas de reintentos, con operadores como retryWhen y onErrorResume, hacen que resista fallos transitorios —como errores de red en SQS o picos de latencia en RabbitMQ— con reintentos exponenciales y fallbacks que evitan pérdidas de datos. Esta fiabilidad da tranquilidad en producción, como saber que tu bólido no se rendirá ante un bache. Además, la flexibilidad del sistema reactivo es como tener un garaje lleno de piezas modulares: puedes recombinar flujos existentes con mínimo esfuerzo, adaptándote a nuevos requisitos sin desmontar la máquina. La inversión inicial —noches de estudio, bugs depurados, sudor— es como construir este bólido desde cero, caro y exigente. Pero cuando lo ves correr, esquivando cuellos de botella, resistiendo tormentas y adaptándose sin esfuerzo, sabes exactamente en qué te gastaste el tiempo. Es una máquina que no solo cumple, sino que brilla en la carretera de producción, dejando claro que cada minuto gastado valió la pena.
Cuando piensas que lo tienes perfecto, surgen “detalles” que ajustar y tienes que apretar aún más las tuercas en algunos puntos. Es entonces cuando aprendes conceptos como jittering procesamiento en canal, en ventana... y ves que tu aplicación se parece cada vez más a un middleware que a una aplicación al uso. Jamás te vas a sentir cómodo. Y eso es bueno. Además forma parte de ese trabajo callado y oscuro que a mi, particularmente, me gusta.
WebFlux brilla en proyectos con altos volúmenes de datos asíncronos y requisitos de baja latencia, como sistemas de streaming, apps de tiempo real o este caso de trading con flujos intensos de mensajes. Su modelo no bloqueante maximiza los recursos, permitiendo manejar grandes cargas con menos infraestructura. Sin embargo, no es para todos los proyectos, no es una bala de plata. Si la app tiene lógicas simples, flujos secuenciales o baja concurrencia, WebFlux añade complejidad innecesaria. Para CRUDs básicos o sistemas con poca carga, Spring MVC es más rápido de desarrollar y menos propenso a errores. La clave es evaluar si el beneficio reactivo justifica el esfuerzo; en este caso, creo que ha sido un gran acierto.
En mi humilde opinión:
Costes iniciales altos: la curva de aprendizaje y el diseño cuidadoso alargan el tiempo de desarrollo. Necesitas bien programadores con experiencia, bien tiempo para formarse. Más horas de testing, ya que los errores reactivos son complejos.
Beneficios para el cliente: en producción, WebFlux reduce drásticamente los costes operativos. Su modelo no bloqueante permite manejar grandes volúmenes de datos con menos recursos, lo que significa facturas de servidores más bajas para el cliente. Además, la robustez de las políticas de reintentos minimizan interrupciones, reduciendo costes de soporte y mantenimiento. La flexibilidad reactiva también permite adaptarse a cambios sin reescrituras costosas, ahorrando dinero a largo plazo. En resumen, WebFlux es una inversión inicial alta que se amortiza rápido para el cliente en proyectos de misión crítica, ofreciendo un sistema eficiente, robusto y económico.
Un consejo que hubiera agradecido al iniciar el proyecto: Imagina que estas programando una shell de consola de Linux. Son programas que hacen cosas muy sencillas muy bien. Además están pensadas para ser encadenadas.