Une entreprise exécute une application de traitement des commandes sur une instance Amazon EC2 qui enregistre les commandes dans une base de données Amazon Aurora. Lors des pics de trafic, l'application ne parvient parfois pas à écrire les commandes assez rapidement. Que doit faire un architecte de solutions pour s'assurer que les commandes sont écrites de manière fiable dans la base de données aussi rapidement que possible ?

La bonne approche consiste à utiliser Amazon SQS comme tampon pour découpler l'application de traitement des commandes de la base de données Aurora. Lorsque le trafic est élevé, les commandes sont d'abord écrites dans la file d'attente SQS. Un groupe Auto Scaling d'instances EC2 peut ensuite lire les messages de la file d'attente SQS et les traiter dans la base de données à un rythme gérable, ce qui assure la fiabilité et la scalabilité. L'Application Load Balancer distribue la charge entre les instances EC2. Augmenter la taille de l'instance EC2 et utiliser SNS n'est pas idéal car SNS est un service de publication/abonnement et non une file d'attente durable pour le traitement des commandes. Écrire directement dans SNS et abonner la base de données n'est pas une pratique courante pour l'ingestion de données transactionnelles. Utiliser SQS uniquement lorsque le CPU atteint des limites et la mise à l'échelle planifiée ne résout pas le problème de manière proactive et fiable lors de pics de trafic imprévus.