Actualizar un sistema en producción no debería implicar que el servicio deje de estar disponible para los usuarios. Y sin embargo, hay muchas aplicaciones donde cada nueva versión implica exactamente eso: una ventana de tiempo en la que el Backend se cae, los usuarios no pueden operar y el negocio se detiene. Este era el problema al que se enfrentaba uno de nuestros clientes del sector transportes. En SETDEVELOPERS rediseñamos la arquitectura completa introduciendo Kafka y Microservicios para eliminar las paradas del servicio y garantizar la disponibilidad continua del sistema.
Necesidad inicial
Un servicio que no podía permitirse parar
El cliente contaba con un Backend que cubría múltiples funcionalidades críticas para su negocio, pero que tenía un problema estructural: cada vez que se desplegaba una nueva versión, el sistema dejaba de dar servicio durante el proceso de actualización. Para un negocio con usuarios activos en distintos horarios, esto no era aceptable.
El objetivo: disponibilidad continua
La necesidad era clara: rediseñar la arquitectura para conseguir que las actualizaciones del software no impactaran en la disponibilidad del servicio y que un fallo en una parte del sistema no arrastrara al resto.
Backend que deja de dar servicio en cada actualización
El problema del monolito
El problema tenía su origen en la arquitectura monolítica del Backend. Toda la lógica de negocio vivía en una única aplicación: cuando había que desplegar una nueva versión, el proceso implicaba parar el servicio, sustituir la aplicación y volver a arrancarlo. No había forma de actualizar una parte sin afectar al todo.
Sin aislamiento, cualquier fallo es total
Este tipo de arquitectura tiene además un problema de resiliencia: si cualquier componente interno falla, ya sea por un bug, un pico de carga o un error en el despliegue, el impacto es total. Un error en el módulo de notificaciones, por ejemplo, podía comprometer la disponibilidad del módulo de autenticación, aunque los dos no tuvieran ninguna relación funcional entre sí. El resultado era un sistema frágil donde cada actualización era un riesgo y cada incidencia tenía el potencial de convertirse en una parada completa del servicio.
Arquitectura de la solución para evitar paradas del servicio
De monolito a Microservicios
El primer paso fue identificar los dominios funcionales del Backend y extraerlos como servicios independientes, cada uno con su propio repositorio, su propio ciclo de vida y su propio proceso de despliegue. Al separar las responsabilidades en unidades más pequeñas y autónomas, conseguimos que la actualización de un Microservicio concreto no afectara al resto del sistema.
Si el equipo necesita desplegar una nueva versión del módulo de procesamiento de datos, lo hace sin tocar el módulo de autenticación ni ningún otro. Además, el aislamiento entre Microservicios actúa como un cortafuegos natural ante los fallos: si un componente tiene un problema, el impacto queda contenido en ese servicio y el resto del sistema sigue operando con normalidad.
Kafka como sistema nervioso central
La segunda pieza clave fue introducir Kafka como plataforma de streaming de mensajería entre los Microservicios. En lugar de que los servicios se comuniquen directamente entre sí mediante llamadas síncronas, publican eventos en topics de Kafka y los servicios interesados los consumen de forma asíncrona. Esto desacopla completamente los productores de los consumidores: ningún servicio necesita saber qué otros servicios van a procesar su información ni cuándo lo van a hacer.
Retención de eventos durante las actualizaciones
Esta arquitectura tiene una ventaja fundamental para la disponibilidad: si un Microservicio consumidor está temporalmente caído o en proceso de actualización, los eventos no se pierden. Kafka los retiene en el topic hasta que el consumidor vuelve a estar disponible y los procesa en el orden correcto. Esto elimina uno de los principales riesgos de los sistemas distribuidos: la pérdida de datos durante las ventanas de mantenimiento.
Detalle de la implementación DevOps para conseguir disponibilidad 100%
Rolling updates en Kubernetes
La arquitectura de Microservicios solo puede garantizar disponibilidad continua si el proceso de despliegue está completamente automatizado. Para esto implementamos una estrategia de rolling updates en Kubernetes: cuando se despliega una nueva versión de un Microservicio, Kubernetes no para las instancias existentes de golpe. En su lugar, levanta instancias nuevas con la versión actualizada de forma gradual, verifica que están respondiendo correctamente y solo entonces elimina las instancias antiguas.
Rollback automático sin intervención manual
Si la nueva versión presenta algún problema durante el despliegue, Kubernetes detecta que las instancias nuevas no superan los health checks y revierte automáticamente al estado anterior, sin intervención manual y sin parada del servicio. Durante todo el proceso, el sistema sigue atendiendo peticiones sin que el usuario perciba ninguna interrupción.
CI/CD integrado en la arquitectura centralizada
Todo este proceso está integrado en la arquitectura centralizada de CI/CD de SETDEVELOPERS, de modo que cada Pull Request mergeada a la rama main desencadena automáticamente el pipeline de despliegue. El equipo no tiene que coordinar ventanas de mantenimiento ni preocuparse por el impacto en los usuarios: el sistema gestiona la actualización de forma segura y transparente.
Ventajas del uso de Kafka y Microservicios
Disponibilidad continua y resiliencia ante fallos
La combinación de Kafka y Microservicios permite actualizar el sistema componente a componente sin ventanas de mantenimiento. Los usuarios no perciben las actualizaciones porque el servicio nunca se detiene. Cuando un Microservicio falla, el impacto queda contenido en ese componente, y Kafka garantiza que los eventos generados durante la incidencia no se pierdan y se procesen en cuanto el servicio se recupera.
Escalabilidad selectiva y reducción de costes
Con una arquitectura monolítica, escalar implica replicar todo el sistema aunque solo uno de sus módulos esté bajo presión. Con Microservicios, se puede escalar de forma selectiva el componente que lo necesita, sin tocar el resto, lo que reduce significativamente los costes operativos.
Una base preparada para crecer
La arquitectura queda preparada para evolucionar: añadir nuevas funcionalidades, integrar nuevos sistemas o modificar la lógica de un dominio concreto son operaciones que se realizan sobre un servicio aislado, sin riesgo de romper lo que ya funciona. El resultado fue un sistema que se actualiza de forma continua, sin paradas, y que absorbe los fallos parciales sin que el usuario final los perciba.
Si tu Backend todavía se cae en cada actualización, cuéntanos tu proyecto y analizamos juntos cómo modernizar su arquitectura.