Consideraciones sobre el diseño

Otros puntos de diseño que se deben tener en cuenta:

• Gestión de errores: si la memoria caché deja de estar disponible por algún motivo, la aplicación debería proceder como si todos los elementos no estuvieran disponibles en la memoria caché. La existencia de la capa de caché no debería añadir fragilidad a la aplicación.

• TTL: es posible configurar un único valor TTL para todas las entradas de la caché o utilizar diferentes valores TTL en función de la entrada (por ejemplo,, get_itemquery, o caché). scan También es posible tener un valor TTL diferente para las entradas de caché negativas (solicitudes que no devuelven ningún elemento).

• Capacidad consumida: cuando devuelvas una respuesta en caché, te recomendamos que ajustes ConsumedCapacity las métricas de la respuesta para indicar un consumo de lectura nulo.

• Eliminación de los metadatos de la respuesta: también debes eliminar la ResponseMetadata sección de la respuesta. Esto evita el riesgo de que alguien vea una RequestId y piense que está actualizada cuando en realidad era de horas antes.

• Añadir metadatos a la caché: es útil añadir una CacheMetadata sección a la respuesta. En esta sección se puede indicar la hora en que se almacenó el valor (útil para medir el grado de obsolescencia) y la biblioteca cliente y la versión en las que se almacenó el valor (lo que puede resultar útil a la hora de realizar una actualización fluida de una versión a otra en la que el formato cambia).

• Determinar el esquema de la tabla: para determinar la clave principal de una operación de escritura para invalidar la caché, debe conocer el esquema de la tabla. Puedes obtener esta información mediante una describe_table llamada y una caché a largo plazo para cada tabla ElastiCache la primera vez que la utilices (solo una vez).

• Aceptar los clientes en lugar de crearlos: una ventaja de aceptar las instancias de cliente de DynamoDB y Redis en el constructor (en lugar de crearlas dentro de la estructura en función de los parámetros transferidos) es que permite a la persona que llama al constructor determinar los detalles, como si deben configurarse. read_from_replicas=True

• Función de espacio de nombres: puede resultar práctico incluir un espacio de nombres opcional en el constructor que aísle todas las lecturas y escrituras de la caché en ese espacio de nombres. El uso de un espacio de nombres es ideal para realizar pruebas, ya que cada ejecución con un espacio de nombres diferente parece empezar con una caché vacía y no tiene efectos secundarios con respecto a las ejecuciones anteriores. También puedes simular que se vacía toda la caché en producción simplemente cambiando el espacio de nombres. Esto se puede implementar agregando automáticamente un prefijo a cada clave de búsqueda.

• Escanear el almacenamiento en caché: es difícil saber si las scan llamadas deben almacenarse en caché. Cuando escanees una tabla completa una sola vez, no querrás llenar la caché con páginas grandes de datos escaneados que no se puedan leer por segunda vez. Por otro lado, muchas cargas de trabajo escanean repetidamente, especialmente si se trata de tablas más pequeñas, para proporcionar los datos más recientes de la tabla completa a varios usuarios intermedios. Una solución sería implementar un sistema en el que se reciban dos llamadas y cada llamada tenga la misma firma (dentro del período de tiempo TTL), para que la respuesta de escaneo resultante se almacene en caché. De este modo, se evita llenar la memoria caché durante un único escaneo completo de la tabla y, al mismo tiempo, se permiten ciclos de escaneo ajustados para aprovechar las ventajas del almacenamiento en caché. El primer escaneo coloca un pequeño marcador de posición en la memoria caché para marcar que la solicitud se ha realizado una vez. El segundo escaneo reemplaza el valor del token por la carga útil real, que puede ser tan grande como 1 MB.