Request coalescing em agentes de IA: como aplicar

Cem agentes pedem o mesmo dado e a origem recebe cem chamadas

Uma política vence no cache às nove horas. Vários agentes começam rotinas ao mesmo tempo. Cada execução percebe a ausência, consulta a mesma fonte e tenta reconstruir a mesma entrada. O banco, a API ou o modelo recebe um pico criado pela própria recuperação.

Request coalescing agrupa solicitações equivalentes que chegam durante uma janela curta. Uma execução assume a busca ou o cálculo. As demais aguardam o mesmo resultado, desde que compartilhem objeto, versão, permissão e finalidade compatíveis.

O mecanismo reduz trabalho duplicado e ajuda a conter cache stampede ou thundering herd. O risco aparece quando uma chave ampla reúne clientes, versões ou autorizações diferentes. Economizar chamadas não pode misturar contextos que deveriam permanecer isolados.

Coalescing e cache resolvem momentos diferentes

O cache para agentes de IA reutiliza um resultado já concluído enquanto ele permanece válido.

Request coalescing atua durante a execução em andamento. Quando várias chamadas equivalentes chegam antes de existir uma resposta armazenada, apenas uma continua até a origem. As outras se ligam ao mesmo trabalho.

A sequência pode ser:

requisição A chega sem cache
→ A se torna líder
→ requisições B, C e D chegam com a mesma chave
→ B, C e D aguardam A
→ A obtém e valida o resultado
→ o sistema entrega o resultado compatível a A, B, C e D

Depois, o resultado pode entrar num cache. Os dois mecanismos se complementam. Cache ruim continua servindo informação vencida. Coalescing ruim espalha um resultado incompatível para várias execuções de uma vez.

O mecanismo é diferente de hedge e lote

O hedged request lança uma segunda chamada equivalente quando a primeira entra na cauda. As duas competem para reduzir latência.

Request coalescing faz o movimento oposto: evita que pedidos simultâneos equivalentes abram várias chamadas.

Processamento em lote reúne unidades diferentes numa operação conjunta, como classificar cem documentos. Coalescing reúne pedidos que querem o mesmo resultado lógico, como buscar a versão vigente da política P-17 para o mesmo escopo autorizado.

Essas distinções importam para métricas e falhas. Hedge aumenta chamadas de forma controlada. Coalescing reduz. Lote muda a unidade de execução.

Comece por leituras caras e repetidas

Candidatos úteis possuem:

alta repetição durante janelas curtas;
mesma entrada lógica;
resultado compartilhável;
custo relevante de consulta ou cálculo;
fonte que suporta uma leitura por vez;
validade verificável;
ausência de efeito externo.

Exemplos:

buscar a mesma política aprovada;
recuperar o mesmo cadastro por ID e versão;
carregar configuração usada por vários workers;
consultar metadados de um documento;
calcular uma representação derivada da mesma entrada;
pedir ao mesmo modelo uma transformação determinística o bastante para a tarefa, com versão e parâmetros fixados;
reconstruir uma entrada de cache expirada.

Evite começar com envio de mensagem, reserva, pagamento, criação de tarefa ou qualquer escrita. Várias unidades podem observar o mesmo resultado de leitura. Elas não deveriam compartilhar uma consequência apenas porque chegaram juntas.

A chave define quem pode compartilhar

A chave de coalescing precisa representar tudo que altera a resposta ou a autorização.

Uma composição pode incluir:

operação + objeto + versão + tenant + papel + finalidade + configuração

Exemplo:

carregar_politica
+ politica_reembolso
+ versao_17
+ tenant_aurora
+ papel_financeiro
+ finalidade_analise
+ idioma_ptbr

Inclua quando relevante:

cliente ou unidade;
usuário ou papel;
escopo de permissão;
região;
finalidade;
versão do objeto;
versão do agente;
modelo e parâmetros;
campos solicitados;
classificação de dados;
instante ou janela de validade.

Uma chave curta demais vaza resultado entre contextos. Uma chave detalhada demais reduz o agrupamento, mas esse é um problema de eficiência. Misturar autorizações é um problema de segurança.

Escolha um líder e registre os seguidores

A primeira execução cria um registro de trabalho em andamento. As seguintes encontram esse registro e decidem se podem aguardar.

Campos úteis:

chave de coalescing;
identificador da execução líder;
início;
prazo;
fonte consultada;
versão esperada;
estado;
seguidores vinculados;
permissões verificadas;
resultado validado;
erro;
expiração do registro;
responsável pela política.

Os estados podem ser:

em_andamento;
concluido_valido;
falhou_sem_resultado;
resultado_incompativel;
expirou;
cancelado.

A aquisição precisa ser atômica. Se duas execuções se tornam líderes ao mesmo tempo, o pico volta a existir.

Cada seguidor mantém o próprio prazo

Compartilhar trabalho não obriga todas as unidades a esperar pelo mesmo tempo.

Uma requisição pode ter prazo de dois segundos. Outra aceita dez. Ambas se ligam ao mesmo líder, mas a primeira pode abandonar a espera antes da conclusão.

O seguidor precisa preservar:

prazo absoluto;
prioridade;
possibilidade de rota alternativa;
estado da unidade original;
regra de cancelamento;
destino depois da espera.

A saída do seguidor pode ser prazo_expirado mesmo quando o líder conclui depois. O resultado tardio ainda pode servir aos seguidores que permanecem válidos ou ao cache, caso passe pelos critérios de publicação.

Cancele o líder somente quando ninguém mais depende dele

Uma unidade pode desistir. O trabalho compartilhado talvez continue útil para outras.

Mantenha uma contagem ou registro de seguidores ativos. Quando um seguidor cancela, retire apenas seu vínculo. Cancele a chamada à origem quando:

o líder perdeu validade;
todos os seguidores saíram;
a fonte deixou de ser autorizada;
o prazo máximo compartilhado terminou;
um circuito bloqueou a dependência;
o resultado não pode mais ser usado ou armazenado.

Uma decisão local não deveria encerrar o trabalho de outras unidades sem verificar dependência.

Trate falha sem criar uma nova manada

Se o líder falha, liberar todos os seguidores para tentar ao mesmo tempo recria o pico.

A política precisa escolher:

eleger um novo líder depois de backoff;
devolver erro compartilhado e encerrar;
usar resultado anterior dentro de uma regra stale-while-revalidate;
encaminhar para uma rota alternativa aprovada;
manter a origem protegida por circuit breaker;
adiar a classe de trabalho;
pedir intervenção quando a fonte exige correção.

A documentação da Microsoft recomenda request coalescing, jitter de TTL, stale-while-revalidate ou lock curto para impedir que várias solicitações reconstruam a mesma entrada expirada. O mecanismo deve respeitar o prazo e a sensibilidade do dado.

Resultado anterior só pode ser usado quando a política permite. Preço, consentimento, saldo, agenda e autorização podem exigir leitura vigente.

Valide antes de distribuir

O líder concluiu tecnicamente. Ainda falta conferir se o resultado serve aos seguidores.

Valide:

objeto correto;
versão esperada;
fonte autorizada;
schema;
escopo de permissão;
finalidade;
classificação de dados;
validade;
cobertura dos campos pedidos;
ausência de erro parcial oculto.

Se seguidores solicitaram projeções diferentes, compartilhe apenas a parte comum quando isso estiver previsto. Outra opção é usar chaves separadas.

Nunca entregue a resposta completa de um usuário privilegiado a outro que pediu um subconjunto. O controle deve acontecer antes da chamada compartilhada e novamente antes da entrega.

Isole clientes e dados sensíveis

Coalescing global maximiza economia e maximiza o raio de uma chave errada.

Use isolamento por:

tenant;
unidade de negócio;
região de dados;
política de retenção;
classe de informação;
conjunto de permissões;
finalidade aprovada.

Para dados pessoais ou estratégicos, prefira reduzir o agrupamento a ampliar exposição. Logs não precisam guardar o payload completo. Registre referências, versões e decisões de autorização.

A página sobre isolamento de clientes em agentes de IA aprofunda identidade, armazenamento e testes negativos entre contas.

Coordene com invalidação e freshness

Uma entrada pode mudar enquanto o líder consulta a fonte.

Carregue a versão esperada ou releia o marcador de atualização antes de publicar o resultado. Quando a fonte muda:

marque o trabalho em andamento como potencialmente vencido;
deixe a chamada terminar se isso ajudar a confirmar o estado;
bloqueie distribuição sem revalidação;
abra outra unidade para a nova versão;
impeça que a resposta antiga ocupe a chave nova.

O guia de freshness de dados ajuda a definir janela útil e fonte de atualização. Coalescing precisa herdar essa política.

Evite estes atalhos

Chave baseada apenas na URL

Cabeçalhos, identidade, campos, idioma e versão podem alterar a resposta.

Compartilhar uma resposta de modelo por texto parecido

Sem equivalência demonstrada, duas perguntas semelhantes podem pedir decisões diferentes. Busca semântica não substitui chave operacional.

Manter o registro em andamento sem prazo

Um líder morto deixa seguidores presos. Use lease, heartbeat quando necessário e recuperação conhecida.

Eleger todos os seguidores depois da falha

A origem recebe a mesma tempestade que o controle deveria evitar.

Ignorar permissões porque a fonte é a mesma

Fonte comum não cria audiência comum.

Usar coalescing para eventos históricos

Eventos financeiros, jurídicos e operacionais que precisam ser preservados individualmente não devem desaparecer num “último valor”.

Teste equivalência, falha e isolamento

Use entradas sintéticas e uma origem controlada. Simule:

dez pedidos idênticos na mesma janela;
mesma chave com prazos diferentes;
dois tenants pedindo o mesmo objeto;
papéis com campos autorizados diferentes;
versão alterada durante a busca;
líder encerrado antes da resposta;
falha da origem;
seguidores cancelando em momentos diferentes;
resultado parcial;
cache expirando sob pico;
nova eleição depois de backoff;
circuito aberto;
resposta tardia;
tentativa de cruzar permissão.

Confira quantidade real de chamadas à origem, seguidores atendidos, prazos, versões, campos entregues, isolamento, estado depois da falha e carga durante a recuperação.

Métricas para operar request coalescing

Acompanhe:

pedidos recebidos;
líderes criados;
seguidores agrupados;
razão entre pedidos e chamadas à origem;
tamanho dos grupos;
tempo de espera por seguidor;
seguidores que expiraram;
líderes que falharam;
novas eleições;
resultados bloqueados por versão ou permissão;
chamadas evitadas;
carga na origem;
custo economizado;
incidentes de compartilhamento incorreto;
chaves com baixa taxa de agrupamento;
responsável e versão da política.

Uma taxa alta de agrupamento pode indicar ganho. Também pode revelar uma chave ampla demais. Eficiência precisa ser lida junto com isolamento e validade.

Checklist de request coalescing

[ ] A operação é leitura ou cálculo sem efeito externo?
[ ] Solicitações equivalentes aparecem na mesma janela?
[ ] A chave inclui tudo que altera resposta e autorização?
[ ] Tenant, papel e finalidade permanecem isolados?
[ ] A escolha do líder é atômica?
[ ] Seguidores mantêm prazo e estado próprios?
[ ] Cancelar um seguidor preserva os demais?
[ ] O líder possui lease e recuperação?
[ ] Falha não libera uma nova manada?
[ ] Resultado passa por validação antes da distribuição?
[ ] Mudança de versão bloqueia resposta vencida?
[ ] Cache e coalescing possuem responsabilidades separadas?
[ ] Logs evitam payload sensível desnecessário?
[ ] Testes cobrem falha, isolamento e recuperação?
[ ] Um dono revisa chaves e métricas?

Uma chamada compartilhada exige uma fronteira precisa

Request coalescing reduz repetição quando várias unidades pedem o mesmo resultado no mesmo intervalo. O ganho depende de uma chave que represente equivalência, autorização e validade.

Comece por leituras caras, escolha um líder, preserve o prazo de cada seguidor, valide o resultado e contenha a recuperação depois de falha. Se a fronteira estiver errada, o sistema economiza exatamente na camada em que deveria isolar.

Fontes oficiais verificadas em 1º de outubro de 2026:

Microsoft Learn: Overview of caching in ASP.NET Core, para proteção contra cache stampede e combinação de operações concorrentes equivalentes.
Microsoft Learn: Improve performance using a cache, para request coalescing, TTL jitter, stale-while-revalidate e lock curto na reconstrução.
Microsoft Learn: Chaos Studio scenarios, para testes de cache stampede, coalescing, backoff e load shedding.

As fontes descrevem padrões de cache e resiliência em plataformas específicas. A aplicação a agentes exige testes com as chaves, permissões, modelos e fontes realmente usados no processo.