Le processus de paiement d'une entreprise de commerce électronique écrit une commande dans une base de données et appelle un service de paiement. Les utilisateurs rencontrent des délais d'attente lors du paiement ; lorsqu'ils soumettent à nouveau, plusieurs commandes uniques sont créées pour la même transaction. Comment un architecte de solutions doit-il restructurer le processus pour éviter les commandes multiples ?

La solution correcte est de stocker la commande dans la base de données et d'envoyer un message à une file d'attente Amazon SQS FIFO (First-In, First-Out). Les files d'attente FIFO garantissent que les messages sont traités une seule fois et dans l'ordre exact où ils sont envoyés, ce qui empêche la création de commandes multiples pour la même transaction. Le service de paiement récupère le message, traite la commande, puis supprime le message de la file d'attente, assurant ainsi une idempotence et une fiabilité. Les autres options ne résolvent pas le problème des commandes multiples : Kinesis Data Firehose est conçu pour la diffusion de données en continu vers des destinations de stockage, pas pour un traitement de messages unique et ordonné. AWS CloudTrail est un service de journalisation et de surveillance, non adapté pour orchestrer des flux de travail de paiement. Amazon SNS est un service de publication/abonnement qui peut livrer des messages à plusieurs abonnés, mais ne garantit pas un traitement unique ou l'ordre des messages comme SQS FIFO.