AWS Lambda em produção: cold start, idempotência e filas de eventos

Resumo executivo

Lambda resolve muito problema de infraestrutura, mas não elimina decisões de engenharia distribuída. Em produção, os incidentes recorrentes aparecem em três frentes:

1. latência inconsistente por inicialização;
2. reprocessamento de eventos sem idempotência;
3. política de retry/destino mal definida.

A boa notícia é que a própria documentação da AWS deixa claros os mecanismos de controle. O ponto é tratá-los como arquitetura, não como tuning tardio.

1) Cold start: problema real, solução contextual

A AWS recomenda reutilizar ambiente de execução (clientes SDK e conexões fora do handler) e ajustar memória com testes de performance. Para workloads interativos, provisioned concurrency reduz latência de inicialização porque mantém ambientes pré-inicializados.

Trade-off importante:

• provisioned concurrency melhora previsibilidade de resposta;
• também aumenta custo fixo.

Decisão prática: use provisioned concurrency onde p95/p99 de latência é requisito de produto, não por padrão em todo o parque.

2) Assíncrono não é “fire and forget” sem contrato

No modelo assíncrono, a API oficial do Lambda documenta comportamento padrão de retry (duas tentativas após erro) e retenção temporária em fila interna. Sem configuração de destino/DLQ, eventos podem ser descartados após esgotar política.

Controles essenciais:

• definir destino de falha (DLQ ou on-failure destination);
• monitorar taxa de falha final, não só erro de primeira execução;
• separar alarmes de erro transitório vs erro terminal.

3) Event source mappings: onde nasce duplicidade

Para Kinesis, DynamoDB Streams, Kafka e outras fontes, a própria documentação reforça que processamento pode ocorrer ao menos uma vez. Isso implica duplicidade possível de evento.

Consequência direta:

• idempotência é requisito funcional, não otimização.

Opções de resiliência como BisectBatchOnFunctionError, limites de retry e idade máxima de registro ajudam isolamento de mensagens problemáticas, mas não substituem desenho idempotente da regra de negócio.

4) Idempotência deve ser explícita no domínio

A AWS recomenda idempotência nas funções e disponibiliza utilitários Powertools para facilitar implementação.

Padrão mínimo recomendado:

• chave idempotente de negócio (não só hash bruto do payload);
• armazenamento de estado da chave com TTL;
• semântica clara para repetição concorrente.

Quando isso não existe, backlog + retry vira multiplicador de efeito colateral (cobrança dupla, envio duplicado, update inconsistente).

5) Checklist operacional de Lambda

1. Definir orçamento de latência por função crítica.
2. Escolher estratégia de concorrência (on-demand, reserved, provisioned) por classe de workload.
3. Configurar destinos de falha para fluxos assíncronos.
4. Garantir idempotência em handlers acionados por fila/stream.
5. Instrumentar métricas de reprocessamento, idade de evento e taxa de descarte.

Times que aplicam esse checklist reduzem incidente sem aumentar complexidade desnecessária.

Conclusão

Lambda em produção é menos sobre “serverless mágico” e mais sobre contrato de execução: latência, retries e consistência.

Pergunta prática para sua operação atual: se o mesmo evento chegar três vezes em 10 minutos, seu sistema preserva exatamente o mesmo estado final?

Fontes

• Best practices for working with AWS Lambda functions - documentação oficial
• Understanding Lambda function scaling - documentação oficial
• Configuring provisioned concurrency for a function - documentação oficial
• PutFunctionEventInvokeConfig (AWS Lambda API) - documentação oficial
• Using Lambda to process records from Amazon Kinesis Data Streams - documentação oficial
• CreateEventSourceMapping (AWS Lambda API) - documentação oficial
• Idempotency utility (AWS Lambda Powertools) - documentação oficial