Refactorización de monolito global enterprise y aceleración de la verificación
Heredé un monolito heredado de años que daba servicio a marcas enterprise globales. La verificación de perfiles y la generación de documentos tardaban 10 minutos por petición, bloqueando servidores web y registros con frecuencia.
Ruby on Rails • Java Spring Boot • Azure
El cuello de botella: una petición de diez minutos
El coste de ese diseño no eran los diez minutos en sí — era lo que esos diez minutos ocupaban. Cada verificación retenía un hilo de petición durante toda su duración, así que un pico modesto de verificaciones simultáneas bastaba para agotar los workers disponibles y dejar al resto de la aplicación esperando detrás de un trabajo que no tenía nada que ver con ella. Usuarios que nunca tocaron la verificación veían ralentizarse la plataforma entera.
El segundo coste era de corrección. Los registros implicados en una verificación quedaban bloqueados mientras corría la generación, de modo que un proceso que fallara a medias dejaba filas retenidas y trabajo a medio hacer, sin forma segura de reintentar — volver a ejecutarlo arriesgaba emitir una segunda copia de un documento ya generado.
La arquitectura: trabajo idempotente, fuera del camino de la petición
Desacoplé la generación síncrona en un pipeline de trabajos asíncronos idempotentes. Dirigí una transición por fases de 11 meses hacia servicios modernos manteniendo la producción disponible sin interrupciones.
Sacar la generación del camino de la petición es la mitad obvia de esa frase. La mitad que decide si funciona es la idempotencia. El trabajo asíncrono es trabajo reintentado — un job que falla, expira o se reentrega volverá a ejecutarse —, así que cada unidad de trabajo tenía que ser segura de ejecutar dos veces. Asignar una clave a cada job para que una repetición produjera el mismo resultado en lugar de un segundo documento es lo que hizo aceptable la entrega at-least-once, y lo que convirtió un fallo parcial de incidente en reintento.
La migración en sí era la restricción más dura. La plataforma daba servicio a marcas enterprise globales y no podía apagarse para un cutover, así que los servicios de reemplazo se levantaron junto al monolito y asumieron responsabilidades de forma incremental, un camino cada vez, dejando el código original en su sitio hasta que su reemplazo estuviera probado bajo tráfico real de producción.
El resultado
La verificación pasó de 10 minutos a 50 segundos — una reducción de latencia de 12x — y la capa web dejó de absorber el coste de un trabajo que nunca perteneció al camino de la petición. El uptime de la plataforma se mantuvo en 99,9% durante toda la transición, con cero interrupciones de servicio.
El resultado duradero es menos visible que la cifra de latencia. Los fallos de verificación pasaron a ser reintentables en lugar de requerir recuperación manual, y desplegar cambios en ese camino dejó de exigir ventana de mantenimiento.
[NDA PROTECTED / ANONYMIZED]