Considérations relatives à la conception

Autres points de conception à prendre en compte :

• Gestion des erreurs : si le cache devient indisponible pour une raison quelconque, l'application doit procéder comme si tous les éléments étaient manquants dans le cache. L'existence de la couche de cache ne doit pas fragiliser une application.

• TTL : Il est possible de configurer une valeur TTL unique pour toutes les entrées du cache ou d'utiliser différentes valeurs TTL en fonction de l'entrée (par exemple, get_itemquery, ou scan cache). Il est également possible d'avoir une valeur TTL différente pour les entrées de cache négatives (demandes n'ayant renvoyé aucun élément).

• Capacité consommée : lorsque vous renvoyez une réponse mise en cache, nous vous recommandons d'ajuster les ConsumedCapacity indicateurs de la réponse pour indiquer une consommation de lecture nulle.

• Suppression des métadonnées de réponse : vous devez également supprimer la ResponseMetadata section de la réponse. Cela évite le risque que quelqu'un voie un RequestId et pense qu'il est à jour alors qu'il date de quelques heures plus tôt.

• Ajout de métadonnées de cache : il est utile d'ajouter une CacheMetadata section à la réponse. Cette section peut indiquer l'heure à laquelle la valeur a été stockée (utile pour mesurer l'obsolescence) ainsi que la bibliothèque cliente et la version qui a stocké la valeur (ce qui peut être utile lors d'une mise à niveau fluide d'une version à une autre lorsque le format change).

• Déterminer le schéma de la table : pour déterminer la clé primaire à partir d'une opération d'écriture pour l'invalidation du cache, vous devez connaître le schéma de la table. Vous pouvez obtenir ces informations en utilisant un describe_table appel et une mise en cache à long terme ElastiCache lors de la première utilisation (une seule fois) pour chaque table.

• Accepter les clients au lieu de les construire : l'un des avantages de l'acceptation des instances des clients DynamoDB et Redis dans le constructeur (au lieu de les créer dans le shim en fonction des paramètres transmis) est que cela permet à l'appelant du constructeur de déterminer les détails, par exemple s'ils doivent être définis. read_from_replicas=True

• Fonctionnalité d'espace de noms : il peut être pratique de prendre en charge un espace de noms facultatif dans le constructeur qui isole toutes les lectures et écritures de votre cache dans cet espace de noms. L'utilisation d'un espace de noms est idéale pour les tests, car chaque exécution avec un espace de noms différent semble commencer par un cache vide et n'a aucun effet secondaire par rapport aux exécutions précédentes. Vous pouvez également simuler le vidage complet du cache en production en modifiant simplement l'espace de noms. Cela peut être implémenté en ajoutant automatiquement un préfixe à chaque clé de recherche.

• Scan de la mise en cache : il est difficile de savoir si les scan appels doivent être mis en cache. Lorsque vous effectuez une analyse complète du tableau une seule fois, il est préférable de ne pas remplir le cache de grandes pages de données numérisées qui ne seront pas lues une seconde fois. D'autre part, de nombreuses charges de travail effectuent des analyses répétées, en particulier sur des tables plus petites, afin de fournir les dernières données complètes des tables à plusieurs consommateurs en aval. Un compromis serait d'implémenter un système dans lequel il faut deux appels, chaque appel ayant la même signature (pendant la période TTL), pour que la réponse de scan résultante soit mise en cache. Cela permet d'éviter de remplir le cache lors d'une seule analyse complète de la table, tout en permettant des boucles d'analyse serrées pour tirer parti de la mise en cache. La première analyse place un petit espace réservé dans le cache pour marquer la demande comme ayant été faite une seule fois. Le deuxième scan remplace la valeur du jeton par la charge utile réelle, qui peut atteindre 1 Mo.