Comment résoudre les éventuels problèmes de cohérence sur AWS

Question

Je travaille sur un projet de gestion de documents (par exemple: créer, lire, gérer différentes versions, etc.) et mon projet est d'utiliser l'architecture AWS suivante.

Lorsqu'un document est créé/mis à jour, il sera enregistré sur une version compatible seau s3 via l'API passerelle proxy S3. L'événement S3 put déclenchera un lambda pour obtenir la dernière version et tous les identifiants de version et l'enregistrera dans DynamoDB. Une fois enregistré sur une table DynamoDB, il sera indexé dans Elasticsearch via le flux DynamoDB.

Mon plan consiste à utiliser Elasticsearch pour toutes les requêtes de recherche. Et je vais charger les derniers documents de DynamoDB. Comme chaque enregistrement a des identifiants de version S3, je peux également interroger les anciennes versions de S3. Depuis mon architecture repose beaucoup sur la cohérence éventuelle à savoir (S3 à DynamoDB et DynamoDB à Elastic Search) Je suis inquiet de ne pas obtenir les dernières données de document soit lorsque j'interroge l'Elasticsearch ou requête DynamoDB après avoir créé un document .

Toute suggestion d'amélioration sera grandement appréciée.

Merci!

Answer 1

Comme vous l'avez dit, l'architecture de votre application comporte plusieurs points où une cohérence éventuelle est utilisée. Si l'analyse de rentabilisation de votre application nécessite absolument que vous interrogiez des données, vous obtenez la dernière version absolue, alors vos choix d'architecture sont mauvais et vous devriez, par exemple, envisager d'utiliser une persistance RDS à la place.

Si ce n'est pas le cas, il vous suffit de concevoir le reste de votre système en gardant à l'esprit que l'obtention d'un PUT complet ne garantit pas que les requêtes renvoient immédiatement les données. Donner des instructions sur la façon de le faire dépend énormément de votre application et ne peut pas être généralisé.

Answer 2

Puisque vous utilisez un flux dynamodb, votre insertion dynamodb atteindra votre serveur de recherche élastique mais avec un délai. En cas d'échec d'écriture, il appartient au client de lancer une nouvelle tentative. Vous devez également garder à l'esprit le temps nécessaire pour déclencher un flux dynamodb et le temps nécessaire pour l'indexation de la recherche élastique (Plus l'événement s3). Donc, votre problème doit faire plus avec le temps qu'il faut pour atteindre le serveur de recherche élastique.

Si vous voulez quelque chose de plus cohérent qui représente l'état actuel (puisque c'est le problème que vous finirez avec), sans aucun délai, vous devez changer les outils.