Ein serverloses System verwendet eine BeginResponse Lambda-Funktion, die Daten initialisiert; danach müssen viele Lambda-Funktionen parallel ausgeführt werden, wobei jede nur von den Ausgaben von BeginResponse abhängt. Jede nachgeschaltete Lambda-Funktion erfordert wiederholbare Aufrufe und eine unabhängige Parallelitätskontrolle, ohne Nachrichten zu verlieren. Welches Design bietet die betrieblich effizienteste Lösung?

Die korrekte Lösung nutzt Amazon SNS für die Verteilung an mehrere Abonnenten und Amazon SQS für die zuverlässige Nachrichtenübermittlung und unabhängige Parallelitätskontrolle. Wenn BeginResponse im SNS-Topic veröffentlicht, wird die Nachricht an alle abonnierten SQS-Warteschlangen gesendet. Jede nachgeschaltete Lambda-Funktion verarbeitet Nachrichten aus ihrer eigenen SQS-Warteschlange, was wiederholbare Aufrufe und unabhängige Skalierung ermöglicht, ohne Nachrichten zu verlieren. Die Option mit direktem SNS-Abonnement der Lambdas ist ungeeignet, da SNS keine Nachrichten speichert und keine unabhängige Parallelitätskontrolle pro Lambda bietet, was zu Nachrichtenverlusten führen kann, wenn Lambdas überlastet sind. Die Option mit separaten SNS-Topics für jede SQS-Warteschlange ist ineffizient, da sie unnötige Komplexität durch viele Topics schafft, wo ein einziges SNS-Topic ausreicht. AWS Step Functions wäre eine orchestrationsbasierte Lösung, die hier nicht die primäre Anforderung der unabhängigen Parallelität und Nachrichtenpersistenz für jede Lambda-Funktion erfüllt, und die sequentielle Ausführung widerspricht der Anforderung der parallelen Ausführung.