Reutilizar el mecanismo de lease de un servicio legado evita cachés obsoletas en migraciones incrementales
Durante la migración de un servicio legado a uno nuevo, se detectó un riesgo de leer datos obsoletos desde la caché en memoria del servicio antiguo. La solución fue aprovechar el mecanismo de lease ya existente para sincronizar las actualiz
Problema de consistencia en la migración
Durante una migración incremental bajo el patrón Strangler Fig, el nuevo servicio escribe directamente en la base de datos mientras el servicio legado sigue sirviendo a los clientes desde su caché en memoria. Cuando la caché del legado no se actualiza, las solicitudes posteriores pueden leer un estado pending aunque la base de datos ya indique completed. El problema se descubrió en pruebas de QA y crecería a medida que se migraran más endpoints.
Restricciones del entorno
El legado es un bloque negro: no se puede modificar su código ni introducir dependencias externas como Redis o Kafka. El mecanismo de cache refresh solo se activa manualmente o de forma periódica, y refrescar la caché completa sería demasiado costoso.
Solución: aprovechar el lease del legado
El servicio legado ya expone una API de lease para recursos individuales: adquirir un lease, liberar y, de forma implícita, refrescar la caché del recurso liberado. Al envolver la operación migrada con:
- adquirir el lease del recurso
- actualizar la base de datos
- ejecutar la lógica de negocio
- liberar el lease el legado se bloquea automáticamente y, al liberarlo, vuelve a cargar solo el dato afectado.
Manejo de fallos
Si la liberación del lease falla por una caída de red, el recurso quedaría bloqueado indefinidamente. El legado ya implementa TTL y un mecanismo de recolección de leases abandonados, lo que garantiza que el bloque se libere después de un tiempo.
Ventajas
- No se añade infraestructura extra.
- Se evita la sobrecarga de refrescar la caché completa.
- Se mantiene la coherencia entre los servicios sin modificar el legado.
Conclusión
Reutilizar un mecanismo interno existente es una forma de resolver problemas de consistencia sin romper las restricciones de una arquitectura heredada. La experiencia muestra que la coordinación con leases puede ser suficiente para mantener la caché del legado en sincronia con la base de datos.
