Un pasillo de centro de datos con racks de servidores y pequeñas luces de estado
RxVantage

RxVantage: Migración a Arquitectura Dirigida por Eventos para SaaS de Salud

Migración a arquitectura dirigida por eventos de un SaaS farmacéutico heredado: más escalable y con 50% de reducción en costos de servidor.

Cliente RxVantage
Sitio web rxvantage.com
Completado
Tecnologías y servicios
Event-Driven ArchitectureMicroservicesMicrofrontendsKubernetesNode.jsReact

Objetivos del proyecto

Transformar una aplicación de salud monolítica en una arquitectura escalable dirigida por eventos usando microfrontends, optimizar los costos de infraestructura sin tiempo de inactividad para operaciones de salud críticas, y reestructurar los equipos de ingeniería para entregar en ciclos más cortos.

El Problema

RxVantage tenía un problema de escalabilidad. Su plataforma de datos farmacéuticos crecía más rápido de lo que aguantaba la aplicación monolítica que sostenía todo. Cada función nueva tardaba más en salir y cada despliegue era motivo de nervios. Los costos de infraestructura no dejaban de subir y el equipo de ingeniería estaba atorado.

La plataforma atendía a profesionales de la salud que toman decisiones sobre el cuidado de sus pacientes, así que una caída no era una simple molestia: era inaceptable. Mientras tanto, la arquitectura existente se doblaba bajo el peso de su propio éxito.

Algo tenía que cambiar. La respuesta fue una migración a arquitectura dirigida por eventos, y tenía que hacerse sin romper nada.

Lo Que Hicimos

Reconstruimos la infraestructura del backend mientras la plataforma seguía funcionando, y quienes la usaban nunca notaron el cambio.

El Cambio de Arquitectura

En lugar de partir el monolito en microservicios tradicionales, pasamos a una arquitectura dirigida por eventos. Los servicios se comunican de forma asíncrona a través de eventos, lo que significa que:

  • Si una parte del sistema recibe mucha carga, no tumba a las demás
  • Cada servicio escala por su cuenta según la demanda real
  • Las funciones nuevas se conectan sin reescribir el código existente
  • Cuando algo falla, falla de forma controlada y no catastrófica

En el frontend dividimos la aplicación en microfrontends, módulos independientes que cada equipo puede desplegar por separado. Ya nadie tenía que esperar a que se reconstruyera toda la aplicación, y los conflictos al integrar código dejaron de frenar los lanzamientos.

La Reconstrucción de la Infraestructura

Construimos desde cero una infraestructura en Kubernetes, pensada para ser eficiente y confiable:

  • Autoescalado que agrega recursos cuando se necesitan y los quita cuando no
  • Procesos de despliegue que llevan el código a producción con mucho menos trabajo manual
  • Monitoreo que detecta problemas antes de que los usuarios los noten
  • Todo definido como código, para poder reconstruir el entorno si hace falta

Lo más difícil fue hacer todo esto sin tiempo de inactividad. Un profesional de la salud no puede quedarse sin acceso a mitad de su turno.

La Transformación del Equipo

Muchos problemas de tecnología son problemas de personas disfrazados. La estructura del equipo de RxVantage generaba cuellos de botella: todos esperaban a todos.

Reorganizamos a los ingenieros en células pequeñas y autónomas. Cada célula era dueña de una parte de la plataforma de punta a punta, del frontend y el backend a la infraestructura. Podían avanzar rápido porque no necesitaban permiso de otros equipos para lanzar una función.

Los capacitamos en patrones dirigidos por eventos, Kubernetes y prácticas modernas de despliegue. Después nos hicimos a un lado.

La Migración

Una migración así no se hace de golpe. Se hace paso a paso y con cuidado.

Corrimos el sistema viejo y el nuevo en paralelo y fuimos pasando el tráfico a la nueva arquitectura poco a poco. Las banderas de funcionalidad nos dejaban controlar exactamente quién veía qué, y si algo salía mal, podíamos revertir al instante.

Empezamos con servicios de bajo riesgo en horarios de poco tráfico. Cuando esos funcionaron, seguimos con las piezas más grandes. Durante todo el proceso monitoreamos rendimiento, errores, comportamiento de usuarios y métricas de infraestructura.

Las apps para celular se volvieron más rápidas, la API más confiable y los despliegues más ágiles. Los usuarios no notaron nada, y de eso se trataba.

Los Resultados

50% de reducción en costos de servidor. La nueva arquitectura usa los recursos de forma eficiente en lugar de mantener todo a máxima capacidad "por si acaso".

30% más rápido en tiempos de despliegue. Con servicios independientes y microfrontends, cada equipo podía lanzar su parte de la plataforma sin esperar a los demás.

10% de aumento en retención de usuarios. Apps más rápidas y un servicio más confiable les dieron a los profesionales de la salud más razones para seguir usando la plataforma.

Cero tiempo de inactividad durante la migración. En una plataforma de la que dependen profesionales de la salud durante su jornada, esto no era negociable.

Con la nueva arquitectura lista, la plataforma quedó preparada para las conversaciones de financiamiento Serie B. Cuando los inversionistas preguntaron por la escalabilidad técnica, la respuesta fue una arquitectura moderna y eficiente, capaz de crecer con el negocio.

Lo Que Aprendimos

Para la resiliencia, los eventos le ganan a los microservicios tradicionales. Con comunicación asíncrona, las fallas no se propagan en cadena. Un servicio puede caerse sin llevarse toda la plataforma.

La estructura del equipo importa tanto como la tecnología. La mejor arquitectura del mundo no sirve si tus equipos no pueden avanzar. Las células autónomas, dueñas de su parte de punta a punta, hicieron más por la velocidad de entrega que cualquier cambio de proceso.

Migrar sin tiempo de inactividad es posible, pero exige disciplina. Requiere sistemas corriendo en paralelo, monitoreo cuidadoso, lanzamientos graduales y la posibilidad de revertir al instante. Es más trabajo al principio, y vale la pena cuando no puedes darte el lujo de un solo minuto fuera de servicio.

La infraestructura como código es la única forma de escalar. Poder reconstruir todo a partir de una definición conocida le da al equipo confianza y margen para moverse.

Lo difícil no es escoger la tecnología correcta. Lo difícil es cambiar un sistema en marcha sin romperlo, y logramos las dos cosas.


¿Necesitas modernizar tu infraestructura o migrar a microservicios? Hablemos →

Ve más de nuestro trabajo Ver casos de estudio →

¿Te gusta lo que ves?

Cuéntanos qué quieres construir y te decimos cómo lo haríamos.

Iniciar un proyecto