Une application mobile de billetterie mondiale affiche un code-barres que les scanners d'événements lisent. Après la lecture, les scanners appellent une API backend pour valider le code-barres par rapport à une base de données, puis mettent à jour une seule table de base de données pour marquer le code-barres comme utilisé. L'entreprise hébergera la base de données dans trois régions AWS et a besoin d'un nom DNS api.example.com. Quelle architecture offre la latence la PLUS FAIBLE pour la validation du code-barres et l'opération de mise à jour ?

La solution correcte utilise Amazon DynamoDB Global Tables pour une réplication multi-régions à faible latence et Lambda@Edge avec CloudFront. DynamoDB Global Tables offre une réplication active-active, garantissant que les écritures et les lectures sont rapides dans toutes les régions. Lambda@Edge exécute le code de validation du code-barres au plus près de l'utilisateur (aux emplacements périphériques de CloudFront), réduisant ainsi considérablement la latence. CloudFront et Route 53 acheminent les requêtes vers l'emplacement périphérique le plus proche, minimisant le temps de parcours réseau. Les options utilisant Aurora Global Database et ECS/EKS nécessitent des appels API entre l'emplacement périphérique et le backend régional, introduisant une latence supplémentaire. De plus, CloudFront avec EKS comme origine ne gère pas la logique métier directement aux emplacements périphériques. L'option CloudFront Function est limitée en complexité et en durée d'exécution, ce qui la rend moins adaptée à la logique de validation et de mise à jour de base de données par rapport à Lambda@Edge.