Interfejs API firmy odbiera dane w czasie rzeczywistym z urządzeń monitorujących i przechowuje je w instancji bazy danych Amazon RDS. Wolumen danych przychodzących zmienia się, a podczas dużego ruchu interfejs API przekracza limit czasu, ponieważ baza danych nie jest w stanie przetworzyć wolumenu zapisu. Architekt rozwiązań musi zminimalizować połączenia z bazą danych i zapewnić brak utraty danych podczas dużego ruchu. Które rozwiązanie spełnia te wymagania?

Poprawne rozwiązanie wykorzystuje Amazon SQS jako bufor, który oddziela API od bazy danych. Gdy ruch jest duży, SQS przyjmuje wszystkie wiadomości, zapobiegając przekroczeniu limitu czasu przez API i utracie danych. Funkcja AWS Lambda, wyzwalana przez SQS, przetwarza wiadomości z kolejki i zapisuje je do bazy danych w tempie, które baza danych może obsłużyć. To rozwiązanie zapewnia asynchroniczne przetwarzanie i skalowalność. Zwiększenie rozmiaru instancji bazy danych (opcja 1) może pomóc, ale nie rozwiązuje problemu nagłych skoków ruchu i nie zapewnia buforowania. Modyfikacja na Multi-AZ (opcja 2) zwiększa dostępność, ale nie skaluje wydajności zapisu w sposób, który rozwiąże problem przeciążenia pojedynczej bazy danych. Amazon SNS (opcja 4) jest usługą publikowania/subskrybowania, a nie kolejką, i nie gwarantuje dostarczenia wiadomości w przypadku, gdy subskrybent (Lambda) nie jest w stanie ich przetworzyć, co może prowadzić do utraty danych.