Eine Wetterdatenlösung empfängt Telemetriedaten von Tausenden von Stationen über eine API Gateway REST API, die in eine Lambda-Funktion integriert ist. Die Lambda-Funktion ruft einen Drittanbieterdienst zur Vorverarbeitung auf; wenn dieser Drittanbieter überlastet ist, schlägt die Vorverarbeitung fehl und Daten gehen verloren. Der Architekt muss sicherstellen, dass keine Daten verloren gehen und die Verarbeitung später erfolgen kann, falls Fehler auftreten. Was sollte der Architekt implementieren?

Die korrekte Lösung verwendet Amazon SQS als Puffer, um Datenverlust zu verhindern und die Verarbeitung zu entkoppeln. Die API Gateway sendet Daten direkt an die primäre SQS-Warteschlange. Eine Lambda-Funktion verarbeitet Nachrichten aus dieser Warteschlange. Wenn die Vorverarbeitung fehlschlägt (z.B. weil der Drittanbieter überlastet ist), kann die Nachricht in die konfigurierte Dead-Letter Queue (DLQ) verschoben werden, anstatt verloren zu gehen. Von der DLQ können die Nachrichten später erneut verarbeitet werden. Option 1 ist unzureichend, da eine DLQ für die API selbst nicht das Problem der fehlgeschlagenen Lambda-Verarbeitung löst, bevor die Daten überhaupt die Lambda erreichen. Option 3 und 4 sind weniger geeignet, da EventBridge zwar für Ereignisrouting nützlich ist, aber SQS besser für die Pufferung und zuverlässige Zustellung von Nachrichten bei variabler Last und Fehlern geeignet ist, insbesondere mit der integrierten DLQ-Funktionalität.