Aplikacja e-commerce korzysta z Amazon API Gateway i funkcji AWS Lambda, przechowując dane w bazie danych Amazon Aurora PostgreSQL. Podczas wyprzedaży gwałtowny wzrost zamówień spowodował przekroczenia limitu czasu. Architekt rozwiązań stwierdził wysokie zużycie procesora i pamięci w bazie danych z powodu wielu otwartych połączeń. Aby zapobiec błędom przekroczenia limitu czasu przy minimalnych zmianach w aplikacji, które rozwiązanie powinien wdrożyć architekt?

Prawidłowa odpowiedź to użycie Amazon RDS Proxy. RDS Proxy to w pełni zarządzana pula połączeń dla baz danych RDS, która obsługuje dużą liczbę połączeń z aplikacji, takich jak AWS Lambda, i efektywnie je ponownie wykorzystuje. Zmniejsza to obciążenie bazy danych związane z nawiązywaniem i zamykaniem połączeń, co obniża zużycie procesora i pamięci. Wymaga minimalnych zmian w aplikacji, jedynie aktualizacji punktu końcowego w funkcji Lambda. Pozostałe opcje są mniej odpowiednie: Konfiguracja provisioned concurrency dla Lambdy nie rozwiązuje problemu z połączeniami do bazy danych, a baza danych globalna nie wpływa na zarządzanie połączeniami. Replikacja do odczytu w innym regionie nie pomaga w przypadku problemów z zapisem ani z zarządzaniem połączeniami, a kierowanie ruchu przez API Gateway do repliki do odczytu jest skomplikowane i nie rozwiązuje problemu z połączeniami do głównej instancji. Migracja do DynamoDB to znacząca zmiana architektoniczna i aplikacyjna, która wykracza poza wymaganie "minimalnych zmian w aplikacji".