O blog da AWS

Mais espaço para construir: serviços Serverless agora oferecem suporte a payloads de até 1 MB

Por Anton Aleksandrov, Prin. SSA, Serverless e Debasis Rath, Sr SSA, Serverless.

Para oferecer suporte a aplicações em nuvem que dependem cada vez mais de dados contextuais ricos, a AWS aumentou o tamanho máximo de payload de 256 KB para 1 MB para invocações assíncronas de funções AWS Lambda, Amazon Simple Queue Service (Amazon SQS) e Amazon EventBridge. Os desenvolvedores podem usar essa capacidade para construir e manter sistemas orientados a eventos ricos em contexto e reduzir a necessidade de soluções alternativas complexas, como divisão de dados ou armazenamento externo de objetos grandes.

Visão geral

Aplicações modernas em nuvem dependem de dados estruturados e ricos em contexto para impulsionar comportamentos inteligentes. Prompts de modelos de linguagem grandes (LLM), sinais de telemetria, dados de personalização, saídas de machine learning (ML) e logs de interação do usuário não são mais strings simples. Em vez disso, eles são tipicamente objetos JSON ou YAML complexos e aninhados que carregam contexto significativo. Anteriormente, desenvolvedores trabalhando com serviços Serverless como Amazon SQS, Lambda (invocações assíncronas e mapeamento de origem de eventos do Amazon SQS) ou EventBridge tinham que gerenciar cuidadosamente seus dados para se ajustarem ao limite de tamanho de payload de 256 KB. Isso comumente significava dividir payloads maiores, externalizar payloads para armazenamentos de objetos como Amazon S3 ou usar compactação de dados. Essas soluções alternativas adicionavam complexidade e latência, criando casos extremos que eram difíceis de monitorar e depurar.

Com os lançamentos recentes, você agora pode transmitir payloads de até 1 MB, reduzindo significativamente a necessidade de divisão complexa de dados e soluções arquiteturais alternativas. Essa capacidade aumentada simplifica padrões de design, reduz a sobrecarga operacional e torna os sistemas orientados a eventos mais intuitivos de construir e manter. Os desenvolvedores agora podem incluir dados mais ricos em payloads únicos—desde prompts LLM detalhados e estados completos do sistema até contexto abrangente e históricos completos de transações.

O novo limite de tamanho de payload de 1 MB se aplica a invocações assíncronas de funções Lambda, seja você as acionando usando mapeamento de origem de eventos do SQS, AWS Command Line Interface (AWS CLI), AWS SDKs, Lambda Invoke API ou serviços AWS como EventBridge. O limite aumentado também se estende a todas as mensagens e eventos fluindo através de filas do Amazon SQS e Event Buses do EventBridge.

Primeiros passos

Não há nada que você precise fazer para começar. Essa capacidade é aplicada automaticamente a todas as funções Lambda, filas SQS e Event Buses do EventBridge novas e existentes.

Se você estava anteriormente dividindo dados no limite de 256KB (ou inferior), então você pode precisar fazer alterações nas configurações de serviço ou no código de lógica de negócios para usar o novo limite. Por exemplo, se você definiu explicitamente o atributo MaximumMessageSize do Amazon SQS, então você pode precisar ajustá-lo para um novo valor desejado. Payloads maiores também podem resultar em custos mais altos, conforme descrito na seção seguinte.

Exemplo do mundo real: contexto rico de eventos em arquiteturas orientadas a eventos agênticas

Arquiteturas orientadas a eventos permitem que os serviços operem independentemente sem coordenação centralizada. Nesses sistemas, o contexto abrangente de eventos é essencial. Com o limite de payload aumentado de 1 MB, os eventos agora podem carregar dados mais abrangentes—desde perfis de usuário e detalhes de pedidos até interações históricas. Isso permite que serviços como inventário, envio e notificações atuem de forma autônoma.

Considere o seguinte exemplo. Nas indústrias de hospitalidade e serviços rápidos, a satisfação do cliente depende de recuperação de serviço oportuna e cuidadosa. Quando um hóspede envia feedback negativo através de uma pesquisa, avaliação ou formulário de reclamação, as equipes de serviço devem reunir contexto, interpretar o problema e elaborar uma resposta. Tradicionalmente, isso significava reunir manualmente logs de visitas, dados de fidelidade e reclamações anteriores. Agora, isso pode ser totalmente automatizado usando um agente de IA baseado em serviços Serverless da AWS e Amazon Bedrock, conforme mostrado na figura a seguir.

Figura 1: Pipeline de processamento de feedback do cliente

O fluxo de trabalho:

  1. Receber: Uma nova avaliação é enviada através da aplicação de avaliação e emitida como um evento para o Event Bus do EventBridge.
  2. Detectar: O Event Bus entrega o evento ao agente de análise de feedback downstream. O agente executando em uma função Lambda reconhece a avaliação como de baixa classificação ou reclamação.
  3. Enriquecer: O agente coleta os metadados de visita do hóspede, detalhes de reserva, atividade de fidelidade e histórico de reclamações usando ferramentas MCP conectadas em um único payload JSON estruturado (até 1 MB).
  4. Adicionar à fila: O payload é enviado para uma fila SQS para processamento assíncrono adicional por componentes downstream.
  5. Gerar: Uma função Lambda separada consome mensagens do Amazon SQS e invoca um modelo do Amazon Bedrock para analisar o contexto completo da reclamação, elaborar uma resposta personalizada, sugerir um gesto (como reembolso ou crédito) e classificar a gravidade do problema.
  6. Entregar: A mensagem é registrada e enviada ao cliente e à equipe de serviço para análise adicional.

Esse caso de uso demonstra a importância de ter um contexto rico: detalhes de visitas atuais e anteriores, nível de fidelidade, interações anteriores e histórico de feedback. Anteriormente, as equipes tinham que mover partes do contexto para o Amazon S3 e referenciá-las externamente, adicionando latência e complexidade arquitetural. O novo tamanho de payload de 1 MB significa que todas essas informações podem ser transmitidas juntas, melhorando a eficiência do fluxo de trabalho agêntico Serverless e simplificando a manutenção.

Melhores práticas ao usar payloads grandes

As seções a seguir descrevem as melhores práticas que você deve aplicar ao usar payloads maiores.

Considerações de desempenho

Monitore cuidadosamente o uso de memória da função Lambda ao trabalhar com payloads maiores, porque analisar e processar objetos JSON complexos pode aumentar o uso de memória e a duração da execução. Teste seus sistemas minuciosamente sob carga, especialmente para aplicações de alto throughput, realizando benchmarks com tamanhos de payload realistas e padrões de tráfego. Embora o limite de payload tenha aumentado para 1 MB, o timeout de 15 minutos do Lambda e os limites de memória permanecem inalterados. Quando aplicável, você pode usar compactação para processar conjuntos de dados ainda maiores de forma eficiente, mas lembre-se de considerar a sobrecarga adicional de CPU de compactação e descompactação em seus cálculos de desempenho. Consulte o post Melhores práticas de monitoramento para entrega de eventos com Amazon EventBridge para conhecer mais práticas recomendadas para ajustar o desempenho de suas arquiteturas orientadas a eventos.

Diretrizes operacionais

Configure filas de mensagens mortas (DLQ) para garantir que mensagens com falha sejam retidas para inspeção e solução de problemas. Isso se torna especialmente importante com payloads maiores, porque depurar estruturas de dados complexas requer acesso ao contexto completo da mensagem. Implemente tratamento robusto de erros e novas tentativas para gerenciar falhas transitórias, particularmente ao processar conteúdo de payload rico que pode conter estruturas aninhadas ou relacionamentos complexos.

Para otimizar ainda mais o throughput, você pode agrupar eventos menores semelhantes em um único payload. No entanto, evite misturar eventos não relacionados e mantenha limites claros entre diferentes domínios de negócios e processos.

Sempre certifique-se de que suas dependências downstream conseguem lidar com payloads maiores.

Quando usar armazenamento externo

Mesmo com o limite de payload aumentado de 1 MB, existem cenários onde padrões como claim check permanecem uma escolha arquitetural sólida. Esses padrões envolvem armazenar um payload completo em um sistema externo, como Amazon S3, e passar uma referência leve através do seu fluxo de eventos. Essa abordagem continua a fornecer valor quando payloads excedem o novo limite, quando os dados precisam ser reutilizados por múltiplos consumidores, ou quando requisitos rigorosos de governança, rastreabilidade e segurança estão envolvidos. Por exemplo, logs de auditoria, metadados de imagem ou grandes entradas de inferência de ML ainda podem ultrapassar o limite de 1 MB, mesmo quando comprimidos. Em vez de arriscar truncamento ou divisão, um claim check permite acesso consistente e escalável ao conjunto completo de dados.

Você pode usar bibliotecas de código aberto como o conector sink Kafka para EventBridge e a Biblioteca de Cliente Estendido do Amazon SQS (disponível para Python e Java) que abstraem as complexidades de armazenar objetos grandes em armazenamento externo.

Gerenciamento de custos

Embora payloads maiores permitam contexto mais rico em suas aplicações, registrar payloads completos pode aumentar os custos de armazenamento e processamento. Serviços como CloudWatch Logs cobram com base no volume de dados, portanto, implementar registro seletivo, truncamento de payload ou amostragem torna-se crucial para eventos de alto volume. Considere registrar apenas campos essenciais ou implementar estratégias de amostragem inteligentes baseadas na importância do negócio.

Para arquivamento e retenção de payload completo, avalie soluções de armazenamento econômicas como Amazon S3 com políticas de ciclo de vida apropriadas. Isso pode incluir mover logs mais antigos para camadas de armazenamento mais baratas ou implementar procedimentos de limpeza automatizados para dados não críticos. Equilibre suas necessidades de retenção com otimização de custos definindo políticas claras sobre quais dados precisam ser mantidos e por quanto tempo.

Revise as páginas de preços para AWS Lambda, Amazon EventBridge e Amazon SQS para saber mais sobre os custos de entrega e processamento de eventos e mensagens.

Conclusão

O aumento no tamanho máximo de payload de 256 KB para 1 MB permite que os desenvolvedores construam arquiteturas distribuídas mais eficientes. Você pode usar esse aprimoramento para transportar contexto mais rico em payloads de eventos e mensagens, reduzindo a necessidade de soluções alternativas complexas que anteriormente adicionavam complexidade arquitetural e sobrecarga operacional. Esse espaço adicional para transmitir contexto mais rico significa que você pode simplificar seus fluxos de trabalho, melhorar a observabilidade e reduzir a complexidade arquitetural, seja usando padrões de coreografia ou orquestração.

Consulte a documentação para AWS Lambda, Amazon EventBridge e Amazon SQS para saber mais sobre como aproveitar esta atualização.

Para saber mais sobre arquiteturas serverless, visite Serverless Land.

Este conteúdo foi traduzido do post original do blog, que pode ser encontrado aqui.

Autores

Anton Aleksandrov, Prin. SSA, Serverless
Debasis Rath, Sr SSA, Serverless

Tradutores

Rodrigo Peres é Arquiteto de Soluções na AWS, com mais de 20 anos de experiência trabalhando com arquitetura de soluções, desenvolvimento de sistemas e modernização de sistemas legados.

Daniel Abib é arquiteto de soluções sênior na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e segurança. Ele trabalha apoiando clientes corporativos, ajudando-os em sua jornada para a nuvem.

https://www.linkedin.com/in/danielabib/