Um site de e-commerce usa uma função Lambda que grava pedidos em um banco de dados Amazon RDS for MySQL. O serviço deve retornar confirmações de pedidos imediatamente. Durante um pico de marketing, a equipe de operações observou erros de "too many connections" do RDS, embora as métricas do cluster de banco de dados mostrem CPU e memória saudáveis. O que o desenvolvedor deve fazer para corrigir os erros de conexão?

A opção correta aborda o problema de "too many connections" de forma eficaz. Abrir a conexão do banco de dados fora do handler do Lambda permite que a função reutilize conexões entre invocações, reduzindo a sobrecarga de estabelecer novas conexões repetidamente. O Amazon RDS Proxy é crucial aqui porque gerencia um pool de conexões de banco de dados, multiplexando as conexões de muitas funções Lambda em um número menor de conexões persistentes com o RDS. Isso evita que o banco de dados seja sobrecarregado por um grande número de conexões simultâneas, especialmente durante picos de tráfego, sem exigir mudanças na lógica de aplicação para gerenciar o pool de conexões. As outras opções são incorretas porque: Aumentar maxuserconnections e reiniciar o cluster pode mitigar o problema temporariamente, mas não resolve a causa raiz do gerenciamento ineficiente de conexões por funções Lambda, que podem escalar rapidamente e abrir muitas conexões. Usar filas SQS FIFO para armazenar pedidos em buffer e ajustar a simultaneidade do Lambda pode ajudar a controlar o ritmo de gravação no banco de dados, mas não resolve o problema de gerenciamento de conexões em si. Além disso, a pergunta especifica que o serviço deve retornar confirmações de pedidos imediatamente, o que não é compatível com o uso de uma fila para processamento assíncrono.