Die API eines Unternehmens empfängt Echtzeitdaten von Überwachungsgeräten und speichert sie in einer Amazon RDS DB-Instanz. Das eingehende Datenvolumen schwankt, und bei hohem Datenverkehr kommt es zu Timeouts der API, da die Datenbank das Schreibvolumen nicht verarbeiten kann. Ein Lösungsarchitekt muss die Datenbankverbindungen minimieren und sicherstellen, dass bei hohem Datenverkehr keine Daten verloren gehen. Welche Lösung erfüllt diese Anforderungen?

Die korrekte Lösung verwendet Amazon SQS als Puffer, um die Datenbank vor Spitzen im Schreibvolumen zu schützen. Die API schreibt Daten schnell in die SQS-Warteschlange, wodurch die Datenbankverbindungen minimiert und Timeouts vermieden werden. Eine Lambda-Funktion verarbeitet die Nachrichten asynchron aus der Warteschlange und schreibt sie in die RDS-Instanz, wodurch sichergestellt wird, dass keine Daten verloren gehen, selbst wenn die Datenbank vorübergehend überlastet ist. Das Erhöhen der DB-Instanzgröße (A) könnte die Leistung verbessern, löst aber nicht das Problem der schwankenden Lastspitzen und minimiert nicht die Datenbankverbindungen. Eine Multi-AZ-Konfiguration (B) dient der Hochverfügbarkeit und dem Disaster Recovery, nicht der Skalierung des Schreibvolumens durch gleichzeitiges Schreiben in alle Instanzen, was zu Dateninkonsistenzen führen würde. Amazon SNS (D) ist ein Publish/Subscribe-Dienst, der für die Verteilung von Nachrichten an mehrere Abonnenten konzipiert ist, nicht als Warteschlange zum Puffern von Daten für eine einzelne Datenbank.