A promessa do Serverless é sedutora: você escreve o código, faz o deploy no AWS Lambda e a infraestrutura escala infinitamente para lidar com qualquer volume de tráfego, cobrando apenas pelos milissegundos de execução. Não há servidores para gerenciar, nem madrugadas perdidas configurando Auto Scaling Groups.
Mas há um detalhe arquitetural que muitos times de engenharia ignoram até que a produção caia: o Lambda escala infinitamente, mas o seu banco de dados relacional não.
Quando você conecta uma aplicação Serverless altamente elástica diretamente a um banco de dados tradicional como o Amazon RDS (PostgreSQL ou MySQL), você está montando uma bomba-relógio. Em momentos de pico, a sua própria arquitetura pode realizar um ataque de negação de serviço (DDoS) contra ela mesma.
A Anatomia do Desastre: O Esgotamento de Conexões
Bancos de dados relacionais foram projetados há décadas, em uma era onde servidores de aplicação (como instâncias EC2) eram estáticos. A boa prática ditava a criação de um Connection Pool (pool de conexões): o servidor abria, digamos, 50 conexões persistentes com o banco e as reutilizava para atender milhares de requisições.
O modelo do AWS Lambda quebra esse paradigma. Como o Lambda é stateless (sem estado), cada vez que ocorre um pico repentino de requisições, a AWS provisiona instantaneamente novos ambientes de execução (os containers do Lambda) para processá-las em paralelo.
Se a sua aplicação recebe um pico de 3.000 requisições simultâneas, a AWS pode subir rapidamente milhares de instâncias do seu Lambda. O problema? Cada uma dessas instâncias tentará abrir uma nova conexão isolada com o Amazon RDS.
Um banco PostgreSQL padrão, dependendo do tamanho da instância, possui um limite rígido (ex: max_connections = 400). Em questão de segundos, o Lambda consome todas as conexões disponíveis.
O resultado:
- Novas requisições começam a receber o temido erro
FATAL: sorry, too many clients already. - Os Lambdas ficam travados esperando uma conexão, aumentando o tempo de execução (e a sua fatura, já que você paga por tempo).
- O consumo de memória e CPU do RDS vai a 100% apenas tentando gerenciar o handshake das conexões.
- O banco de dados cai. Sua própria aplicação acabou de fazer um “DDoS interno”.
Como Evitar o Colapso: Padrões de Arquitetura
Para unir o mundo elástico do Serverless com o mundo rígido dos bancos relacionais, precisamos de camadas de amortecimento. Aqui estão as duas abordagens definitivas:
1. Multiplexação com Amazon RDS Proxy
A AWS criou um serviço específico para resolver essa dor. O Amazon RDS Proxy atua como um intermediário entre as suas funções Lambda e o seu banco de dados.
Em vez de o Lambda se conectar diretamente ao RDS, ele aponta para o endpoint do RDS Proxy. O Proxy mantém um pool de conexões robusto, persistente e seguro com o banco de dados. Quando milhares de Lambdas são instanciados, eles se conectam ao Proxy. O Proxy, por sua vez, enfileira, compartilha (multiplexa) e reutiliza as poucas conexões que ele tem abertas com o RDS de forma inteligente.
O banco de dados não sofre o impacto da avalanche de conexões, a latência de inicialização do Lambda (Cold Start) melhora, e a aplicação sobrevive a picos massivos sem derrubar o RDS.
2. Achatamento de Curva com Amazon SQS
Se a operação que o Lambda realiza no banco de dados for assíncrona (como salvar um log de evento, processar um pedido em background ou gerar um relatório), a melhor defesa é não acessar o banco diretamente na borda.
Implemente o padrão de mensageria: a API Gateway recebe a requisição e a joga em uma fila do Amazon SQS. O Lambda é configurado para consumir essa fila com uma concorrência máxima controlada (ex: máximo de 10 Lambdas simultâneos lendo lotes de mensagens). Mesmo que entrem 100 mil requisições por segundo na fila, apenas 10 Lambdas estarão gravando no banco de dados por vez. Você troca instantaneidade por estabilidade arquitetural (achatamento de curva).
Conclusão
Migrar para Serverless exige mais do que apenas reescrever o código de um servidor para uma função. Exige repensar como o estado e as dependências são gerenciadas.
Proteger o seu banco de dados relacional com o RDS Proxy ou com filas SQS é a diferença entre uma arquitetura que brilha na Black Friday e uma arquitetura que derruba a operação da empresa nos primeiros minutos do evento.
