El paciente que creía tener microservicios (Spoiler: no los tenía)

El viernes pasado llegó a mi consulta un caso que me recordó por qué me especialicé en arquitectura de sistemas.

“Doctor,” dijo el Tech Lead, claramente agotado, “nuestro sistema está enfermo. Empezamos con microservicios hace dos años, todo parecía perfecto en papel, pero ahora… cada deploy es una pesadilla y nuestros usuarios se quejan constantemente.”

Le pedí que describiera los síntomas.

“Bueno, para empezar, ya no podemos hacer deploys independientes. Cuando actualizamos el servicio de usuarios, invariablemente algo se rompe en carritos de compra o pagos. El otro día cambiamos un campo en una API y tuvimos que actualizar seis servicios diferentes.”

Primera bandera roja. Los microservicios que no se pueden desplegar independientemente no son microservicios.

Continuó: “Y las caídas… Doctor, es horrible. La semana pasada nuestro servicio de inventario cayó cinco minutos y TODO dejó de funcionar. Los usuarios ni siquiera podían iniciar sesión porque, al parecer, el login necesita validar algo con inventario.”

Segunda bandera roja. Efecto dominó. Un síntoma clásico.

“Pero lo peor,” continuó con una sonrisa amarga, “es el debugging. Ayer un usuario reportó que no podía completar una compra. Para rastrear el error tuve que revisar logs de ocho servicios distintos, correlacionar IDs en todo el sistema, y finalmente descubrir que el problema era un timeout en un servicio que ni sabía que estaba involucrado en el checkout.”

Bingo. Monolito Distribuido en plena acción.

Mi diagnóstico fue inmediato: Síndrome del Monolito Distribuido

“Mira,” le expliqué, “no tienes microservicios. Tienes un monolito al que alguien le cortó en pedazos y distribuyó por la red. Es como tomar un reloj, desarmarlo, poner cada pieza en una caja diferente, y luego preguntarse por qué ya no da la hora.”

Le mostré el problema en términos simples:

“En un sistema de microservicios saludable, cuando un usuario actualiza su dirección, el servicio de usuarios simplemente dice ‘Oye, este usuario cambió su dirección’ y listo, responde de inmediato. Si el servicio de envíos quiere saberlo para recalcular costos, que se suscriba a ese evento y lo procese cuando pueda. Si envíos está caído, el usuario igual puede cambiar su dirección.”

“Pero ¿cómo manejo la consistencia?” preguntó, con la preocupación típica.

“Piénsalo así: en el mundo real, cuando te mudas, no te quedas parado en la puerta esperando a que Amazon, Netflix, tu banco y tu mamá actualicen simultáneamente tu dirección. Notificas el cambio y cada uno actualiza cuando puede. Es consistencia eventual, y funciona perfectamente.”

La receta: Arquitectura Orientada a Eventos

“El tratamiento es gradual,” le expliqué. “Comenzamos con un evento simple. Toma tu operación más problemática — digamos, el registro de usuarios. En vez de que el servicio de usuarios llame directamente a perfiles, notificaciones y analíticas, haz que publique un evento UserRegistered y deja que cada servicio reaccione de forma independiente.”

Le conté sobre un cliente anterior: “Una startup de delivery que tenía exactamente tu problema. Cada pedido requería coordinación entre siete servicios. Un timeout en cualquier lugar y el pedido fallaba. Migramos a eventos en dos meses. Ahora procesan 10 veces más pedidos, y cuando un servicio falla, el resto sigue funcionando. Los usuarios ni se enteran.”

El momento ‘ajá’

“Pero Doctor,” me interrumpió, “¿no será más complejo manejar eventos?”

“Al contrario,” respondí. “La complejidad ya existe en tu sistema, pero está oculta en todas esas llamadas síncronas entre servicios. Los eventos hacen esa complejidad visible y manejable. Es como encender la luz en una habitación oscura: no elimina los muebles, pero ahora puedes verlos y no tropezar con ellos.”

Seis meses después…

Recibí un mensaje: “Doctor, el tratamiento funcionó. Ayer nuestro servicio de recomendaciones estuvo caído dos horas y nadie lo notó hasta que revisamos los logs. El sistema siguió funcionando perfectamente. Por primera vez en dos años, dormí bien durante un deploy.”

Ese es el poder de la arquitectura orientada a eventos. No se trata de tecnología sofisticada; se trata de construir sistemas que respiran, que fallan con gracia, que evolucionan sin romperse.

Si tu sistema muestra estos síntomas, no lo postergues. La enfermedad del Monolito Distribuido solo empeora con el tiempo.