Propuesta para cambiar los métodos para ingresar y leer el cache, para acelerar los tiempos de lectura y no tener que leer datos vencidos.
Actualmente en el sistema las rutas que son ingresadas al cache se ingresan durante un dia. No existe un mecanismo para invalidar el cache, para modificar el tiempo de vida o para realizar el ingreso de datos que tienen alta volatilidad.
Actualmente dentro de los repositorios del SDK se consulta el cache y si existe una ruta guardada se sirve ese dato
if (!$attributes = $this->cache->get(static::CACHE_TARGET, $sellerCode)) {
Al no tener acceso a un gateway / sistema de eventos esto no se puede cambiar. Existen alternativas: https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-caching.html
Lo siguiente es luego de no encontrar datos en el cache y hacer el pedido al microservicio, guardar los datos durante 1 día.
$attributes = json_decode($response->getBody()->getContents(), true);
$this->cache->save(static::CACHE_TARGET, $sellerCode, $attributes);
Esto trae los siguientes problemas
a) Cualquier modificación en el tiempo de vida implica modificaciones al SDK
b) La lógica de como guardar los datos esta centraliza en el SDK que no tiene forma de invalidar los datos cuando cambia la base de datos.
Comenzar a guardar los datos del cache dentro de los microservicios:
-
Crear un middleware que, en base a una configuración, guarde en el cache respuestas que haya que persistir en el cache
-
Crear un archivo de configuración / variables de entorno que determinen el tiempo de vida y si deben ser o no cachadas. Ej:
'seller' => [
'ttl' => 60,
'key' => 'seller' // la key puede ser en base a la ruta y no una constante
]
- Que cuando un modelo / ruta que afecten los datos guardados en el cache se ejecute, disparar un evento que invalide el cache
La desventaja es que se empieza a ingresar lógica a los microservicios de como manejar el cache que antes se centralizaba en el SDK lo cual hace que un fallo en los datos pueda encontrarse en el microservicio / SDK.
También al ingresar métodos de invalidación manualmente pueden ignorarse casos que hagan que el cache no se invalide correctamente.
a) Dejar que el gateway maneje el cache e invalidarlo mediante requests que vacíen los datos guardados. https://stackoverflow.com/questions/51195109/how-to-invalidate-aws-apigateway-cache
https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/azure-caching
b) Usar un microservicio dedicado al manejo del cache
Use case 1: On-demand cache to reduce real-time calls
En el caso de rutas que utilizan muchos filtros y cuyos registros cambian todo el tiempo la forma de escribir el cache "aside" no sirve, ya que debe invalidarse el cache cada vez que se ingresa un registro y esto ocurre de manera constante.
Establecer una estrategia de cache que sincronice la tabla de la base de datos y el cache Existen varias técnicas dependiendo de la consistencia que se necesite. Por ejemplo write-trough escribe a la base de datos y al cache y cuando hay que consultar un registro se busca directamente en el cache
Tipos: https://danielw.cn/cache-consistency-with-database (en particular write-through)
Ejemplo AWS:
Use case 2: Proactive caching of massive volumes of data
Implica tener en memoria una tabla entera y lleva mas tiempo cargar registros. Ademas ya no se usaria SQL para consultar los datos. Si se quiere usar redis por ejemplo se tendria que usar Spark SQL para realizar consultas complejas sobre los datos.
Usar otro tipo de almacenamiento, por ejemplo dynamodb + dax, que soporte cache