L'API d'une entreprise reçoit des données en temps réel de dispositifs de surveillance et les stocke dans une instance de base de données Amazon RDS. Le volume de données entrant fluctue et, en cas de trafic intense, l'API expire car la base de données ne peut pas traiter le volume d'écriture. Un architecte de solutions doit minimiser les connexions à la base de données et garantir l'absence de perte de données en cas de trafic intense. Quelle solution répond à ces exigences ?

La solution correcte consiste à utiliser Amazon SQS et AWS Lambda. Amazon SQS est un service de file d'attente de messages qui peut absorber des volumes de données fluctuants, découplant ainsi l'API de la base de données. Cela empêche les expirations de l'API pendant les périodes de trafic intense et garantit qu'aucune donnée n'est perdue. Une fonction AWS Lambda peut ensuite traiter les messages de la file d'attente et écrire les données dans la base de données RDS à un rythme gérable, minimisant ainsi les connexions directes à la base de données. Augmenter la taille de l'instance de base de données peut améliorer les performances, mais ne résout pas le problème fondamental des pics de trafic qui peuvent submerger la base de données. Une instance Multi-AZ améliore la disponibilité et la résilience, mais pas la capacité d'écriture pour un seul point de terminaison de base de données. Écrire sur plusieurs instances Multi-AZ n'est pas une pratique standard pour la mise à l'échelle des écritures et peut introduire des problèmes de cohérence. L'utilisation d'Amazon SNS n'est pas idéale pour ce cas d'utilisation, car SNS est un service de publication/abonnement et ne fournit pas de file d'attente durable pour les messages non traités, ce qui pourrait entraîner une perte de données si la fonction Lambda échoue ou est surchargée.