Francisco Airam Hernández Crosa

Desafío Técnico

La aplicación presentaba una degradación relevante del rendimiento con tiempos de respuesta superiores a los 2 segundos en sus endpoints principales. El origen del problema radicaba en la sobrecarga en la transferencia de datos debido al comportamiento Eager Loading implícito en las relaciones @ManyToOne, la proliferación del problema de consultas N+1, y una ineficiente estrategia de paginación procesada en memoria (mediante el uso de subList de Java), lo que ponía en riesgo la estabilidad del sistema al escalar el volumen de datos.

Estrategia de Refactorización y Arquitectura de Persistencia

El sistema implementa una reestructuración de las capas de persistencia, servicios y entidades de la aplicación, abstrayendo la lógica redundante y delegando la carga pesada de datos directamente al motor de la base de datos de manera eficiente.

• Carga Perezosa: Modificación de las relaciones estructurales en la capa de entidades para evitar la recuperación innecesaria de objetos adjuntos en memoria de forma por defecto.
• Resolución Eficiente de N+1: Implementación guiada de JOIN FETCH y EntityGraphs en la capa de persistencia, reduciendo los accesos recursivos al motor relacional.
• Anotación Transaccional Optimizada: Uso estricto de @Transactional(readOnly = true) en métodos de consulta para optimizar los flujos de lectura en gran medida y reducir de forma significativa el proceso de dirty checking de Hibernate en operaciones de lectura.
• Centralización con Enfoque DRY: Implementación de métodos genéricos de filtrado en repositorios personalizados, logrando la eliminación de la mayor parte de la lógica duplicada.

Flujo de Ejecución y Paginado más Eficiente

Análisis Comparativo de Tiempos de Respuesta

El impacto del rediseño multicapa se evidencia en la reducción de los tiempos de respuesta y en la previsibilidad de la carga en todo el sistema de la aplicación:

Nota sobre la consistencia: Incluso en procesos que ya contaban con un rendimiento óptimo (<100ms), se logró una reducción del 50% en el tiempo de respuesta, favoreciendo una experiencia de usuario predecible y con una latencia más consistente.

Desafío Técnico

Migración de un histórico acumulado de más de 10 millones de registros con 15 años de recorrido. El proceso original secuencial tardaba más de 5 horas en completarse. El motor de base de datos sufría por la ejecución recursiva de subconsultas dinámicas lookup (aproximadamente 38 millones de subconsultas select) destinadas a resolver claves foráneas e integridad referencial en caliente para cada fila insertada, bloqueando la base de datos durante las ventanas de mantenimiento técnico.

Arquitectura y Optimización en Memoria

La solución implementada redujo las consultas de base de datos tipo N+1 durante el bucle de inserción, resolviendo todas las dependencias relacionales en caliente dentro de la JVM.

• Precarga en Caché O(1): Carga inicial de diccionarios de lookup en memoria Java, resolviendo claves naturales a identificadores secuenciales en microsegundos y ocupando solo ~420 MB del Java Heap.
• Concurrencia con & Thread Pools: Segmentación dinámica de los streams de datos históricos procesados de forma concurrente, aislando la escritura en disco de cada hilo.
• Thread-Safety Garantizada: Uso de mapas de solo lectura tras la carga inicial y generación secuencial atómica de IDs para prevenir condiciones de carrera.

Flujo de Ejecución en Tres Fases

Ejemplo de Transformación SQL (Esquema Anonimizado)

ANTES: SQL Generado con Subconsultas Lookup Recursivas

INSERT INTO DETALLE_TRANSACCION (transaccion_fk, cod_detalle, info_pago, fecha_creacion)
VALUES (
  (SELECT MAX(id) FROM TRANSACCIONES t WHERE t.usuario_fk = (SELECT id FROM USUARIOS u WHERE u.token_acceso = 'USR-2026-X98A')),
  'DET-90234', 'INFO_MOCK', '2026-07-05 13:00:00'
);

AHORA: SQL Generado con Identificadores Directos Precalculados

INSERT INTO DETALLE_TRANSACCION (transaccion_fk, cod_detalle, info_pago, fecha_creacion)
VALUES (
  3489102, -- ID precalculado de forma eficiente en memoria Java (O(1))
  'DET-90234', 'INFO_MOCK', '2026-07-05 13:00:00'
);

Análisis Compartivo por Latencia de Red (10M de Registros)

El tiempo total del proceso varía según la latencia de red al servidor de base de datos debido al volumen de subconsultas lookup del método anterior. A continuación se detallan los tres escenarios analizados:

Nota sobre el cálculo: En el entorno real, el tiempo de procesamiento se redujo de 5 horas a 3 minutos para el lote de datos ejecutado bajo una latencia media de red corporativa (~1.1 ms promedio por consulta lookup).

Conclusión

La optimización del proceso ETL no solo mejoró el tiempo de ejecución en un 99%, sino que cambió la dinámica de trabajo del equipo. Al reducir el tiempo de 5 horas a 3 minutos, pudimos iterar y validar la migración más de 60 veces durante la fase de pruebas. Esto nos ahorró semanas de trabajo manual y nos permitió detectar inconsistencias en los datos que, de otra forma, habrían sido catastróficas en el entorno de producción

Desafío Técnico

Un backend con CQRS (escritura en Primary, lecturas en Replica), caché distribuida en Redis y eventos de auditoría via Kafka tiene múltiples puntos de fallo. Un timeout de Redis o una caída de la réplica no deberían provocar errores 500 al usuario.

Arquitectura del Sistema

4 Circuit Breakers independientes (Resilience4j) monitorizan cada servicio. Un HealthChecker proactivo testea las conexiones cada 3-5 segundos y abre el circuit breaker antes de que una petición real falle. Al levantar una incidencia o recuperación, se publica un Spring Event que un WebSocketNotificationService traduce a alertas STOMP al frontend.

• CQRS con fallback automático: si la réplica falla, un AOP Aspect redirige las lecturas al Primary vía ScopedValue (Java 25), sin cambiar una línea de código de negocio.
• Caché circuit-breaker-aware: un CircuitBreakerAwareCacheManager envuelve cada operación Redis. Con el CB abierto, toda operación de caché se convierte en cache-miss: la app sigue funcionando sin caché.
• Outbox resiliente: el procesador de Kafka comprueba el estado del CB antes de cada batch. Si Kafka no está disponible, los eventos quedan en la tabla Outbox (PostgreSQL) hasta la recuperación, con Gauge de Prometheus para monitorizar el lag.
• JWT Blacklist con failover: Redis → DB automático. Si Redis falla, la verificación de tokens revocados se hace contra PostgreSQL sin interrupción.

Flujo de Detección y Recuperación

Degradación por Servicio

El impacto de una incidencia se gestiona de forma aislada para favorecer la alta disponibilidad parcial:

• Replica no disponible: lecturas redirigidas al Primary. Impacto: mayor carga en Primary, errores mitigados para el usuario.
• Redis no disponible: cache-miss universal, consultas van directo a DB. Blacklist JWT cae a PostgreSQL.
• Kafka no disponible: eventos de auditoría acumulados en tabla Outbox. Se envían cuando Kafka vuelve (entrega garantizada).
• Primary no disponible: operaciones de escritura fallan con error controlado. Lecturas siguen via Replica si está sana.

Cobertura de Testing

• Tests de integración que abren cada CB y verifican que se envía la alerta WebSocket correcta (DB_FAILURE, REDIS_RECOVERED, etc.).
• Test end-to-end de resiliencia: confirma que @Cacheable no lanza excepción con Redis CB abierto.
• Test de failover JWT: verifica que si Redis no responde, la blacklist cae a PostgreSQL sin interrupción.
• Test de notificación a nueva conexión WebSocket: usuario que conecta recibe el estado actual de CBs abiertos.

Conclusión

Arquitectura diseñada para una degradación controlada / alta disponibilidad parcial: la aplicación continúa operativa para los casos soportados aunque ocurran fallos en servicios auxiliares. La detección proactiva (health checks cada 3s) reduce el tiempo medio de detección frente al enfoque reactivo tradicional, y el WebSocket permite al frontend mostrar banners informativos en vez de errores genéricos.