Ordem de mensagens em filas de agentes de IA

O pedido foi entregue antes do cancelamento

Um agente recebe dois eventos sobre o mesmo pedido. O primeiro registra uma alteração de endereço. O segundo cancela a compra. Durante uma recuperação da fila, o cancelamento chega ao consumidor antes da alteração. Minutos depois, o evento atrasado tenta atualizar um pedido que já deveria permanecer encerrado.

As duas mensagens são válidas. O erro aparece na sequência em que seus efeitos alcançam o estado oficial.

A ordem de mensagens em filas de agentes de IA precisa ser definida pela unidade empresarial que exige sequência, como pedido, oportunidade, chamado ou documento. A arquitetura também precisa reconhecer eventos atrasados, duplicados e reentregues. Colocar tudo numa fila FIFO global preserva uma sequência ampla demais e pode reduzir a capacidade sem proteger o objeto correto.

Qual problema este guia resolve

Este recorte trata fluxos assíncronos em que dois ou mais eventos relacionados podem produzir resultados diferentes conforme a ordem de processamento.

A pergunta operacional é:

Quais mensagens precisam manter sequência entre si e como impedir que um evento antigo sobrescreva um estado mais novo?

O controle de concorrência em agentes de IA protege escritas sobre objetos que mudaram. O guia de visibility timeout trata posse temporária e reentrega. A fila justa para agentes multicliente distribui espera entre grupos.

A ordenação possui outro trabalho: preservar a sequência dentro de uma fronteira específica e tornar mensagens tardias identificáveis. Esses controles podem atuar juntos.

Descubra onde a ordem altera o resultado

Nem toda mensagem precisa de ordem estrita. Uma fila de análise de documentos independentes pode processar vários arquivos em paralelo. Já os eventos do mesmo pedido podem representar uma sequência de estados que não aceita inversão.

Procure invariantes como:

um pedido cancelado não volta para em separação por causa de evento antigo;
uma oportunidade ganha não recebe uma recomendação baseada no estágio anterior;
uma revogação de acesso prevalece sobre uma concessão mais antiga;
a versão mais recente de uma política substitui a anterior;
um pagamento confirmado não retorna para cobrança por atraso na integração;
uma tarefa concluída não reaparece como pendente;
uma resposta do cliente invalida um follow-up preparado antes dela.

A ordem importa quando uma mensagem depende do estado produzido por outra ou quando uma transição posterior torna a anterior inválida.

Escolha a chave de ordenação pelo objeto

Serviços de fila costumam preservar ordem dentro de um grupo, não no sistema inteiro. O grupo deve representar a menor unidade que precisa de sequência.

Exemplos:

| Processo | Chave possível | Sequência protegida | |---|---|---| | pedidos | pedido_id | criado, pago, separado, enviado, cancelado | | CRM | oportunidade_id | estágio, resposta, próxima ação, encerramento | | atendimento | caso_id | abertura, mensagem, escalonamento, resolução | | acesso | solicitacao_id ou identidade_recurso | pedido, aprovação, concessão, revogação | | documento | documento_id | versão recebida, revisão, aprovação, substituição | | agenda | recurso_intervalo | reserva, confirmação, remarcação, cancelamento |

Uma chave global serializa trabalho sem relação. Uma chave diferente em toda mensagem elimina a sequência. Uma chave ampla demais, como cliente_id, pode deixar milhares de objetos esperando atrás de uma única tarefa lenta.

A chave também precisa vir de fonte autorizada. Texto livre fornecido pelo usuário não deve decidir qual cliente, conta ou processo divide a mesma sequência.

Ordem por objeto preserva paralelismo

Na documentação oficial verificada em 25 de setembro de 2026, o Amazon SQS FIFO usa MessageGroupId para preservar ordem dentro de cada grupo. Enquanto mensagens do grupo A avançam em sequência, grupos B e C podem ser processados em paralelo.

O Google Cloud Pub/Sub usa ordering key para agrupar mensagens relacionadas. A documentação informa que mensagens com a mesma chave precisam ser publicadas na mesma região para receber a garantia descrita pelo serviço. A assinatura também precisa ter ordenação habilitada.

O princípio arquitetural é útil além desses produtos:

identifique o objeto empresarial;
derive uma chave estável;
preserve sequência dentro dessa chave;
permita paralelismo entre objetos independentes;
valide versão e estado antes do efeito.

A implementação exata muda conforme fila, região, biblioteca, modo de consumo e limite contratado. A garantia do fornecedor possui escopo. Ela não transforma um CRM, ERP ou sistema financeiro em destino idempotente.

A fila conhece chegada, não toda a história do negócio

Uma fila pode entregar na ordem em que recebeu mensagens e ainda assim receber eventos atrasados da origem.

Considere esta sequência:

10:00: pedido criado, versão 1
10:03: pedido cancelado, versão 3
10:05: integração antiga publica alteração de endereço, versão 2

A fila recebeu primeiro a versão 3 e depois a versão 2. Entregar nessa mesma ordem reproduz fielmente a chegada, mas aplicar a versão 2 devolveria o objeto ao passado.

Por isso, cada mensagem deve carregar informação suficiente para o consumidor avaliar validade, como:

object_id: PED-4821
object_version: 3
event_id: EVT-9087
event_type: pedido_cancelado
occurred_at: 2026-09-25T10:03:00Z
published_at: 2026-09-25T10:03:04Z
source: erp_pedidos
ordering_key: PED-4821
causation_id: CMD-7712

O consumidor compara object_version com o estado conhecido. Uma versão menor pode ser marcada como atrasada. Uma versão igual com outro event_id exige investigação. Um salto de versão pode indicar evento ausente.

Horário ajuda a investigar, mas raramente basta para decidir. Relógios divergem, eventos são publicados depois e sistemas usam fusos diferentes. Versão ou sequência definida pela fonte costuma oferecer uma referência mais forte.

Separe quatro tipos de ordem

Ordem de publicação

Representa a sequência em que o produtor entregou mensagens à fila. Depende do comportamento do produtor, da região e da garantia do serviço.

Ordem de entrega

Representa a sequência em que o consumidor recebe as mensagens. Retentativas, falhas e configurações da assinatura podem influenciar o comportamento.

Ordem de processamento

Representa quando cada worker executa o trabalho. Uma mensagem recebida primeiro pode terminar depois quando sua tarefa é mais lenta.

Ordem de compromisso

Representa a sequência aceita pelo sistema oficial. É a camada que decide se um efeito ainda pode alterar o objeto.

Preservar entrega não garante compromisso. Dois workers podem receber grupos diferentes e disputar um objeto mal identificado. Uma ferramenta externa pode responder tarde. Uma aprovação pode ocorrer sobre uma versão vencida.

O controle final deve ficar perto da escrita que muda o negócio.

Use versão para bloquear evento antigo

Antes de aplicar uma transição, o consumidor consulta ou tenta atualizar o objeto sob condição de versão.

Exemplo:

estado atual: cancelado
versao atual: 3
mensagem recebida: endereco_alterado
versao da mensagem: 2

A regra recusa a transição e registra:

resultado: evento_atrasado_bloqueado
objeto: PED-4821
versao_recebida: 2
versao_atual: 3
consequencia_evitada: alterar pedido cancelado
proxima_acao: nenhuma, salvo investigação de lacuna

Uma mensagem recusada por versão não deve entrar em retentativa cega. A repetição não tornará o evento mais novo. Ela precisa seguir para descarte controlado, auditoria ou reconciliação, conforme consequência e política.

Se o destino aceita ETag, If-Match, comparação e troca ou condição sobre a versão, aplique o gate na própria escrita. Consultar e depois atualizar sem condição abre outra janela de corrida.

Trate versões ausentes sem adivinhar

O consumidor recebe a versão 8, mas o estado local conhece apenas a versão 6. Existem algumas possibilidades:

a versão 7 está atrasada na fila;
a versão 7 falhou na publicação;
o consumidor perdeu a mensagem;
a fonte compactou duas mudanças;
a numeração não representa uma sequência contínua;
outro sistema atualizou o objeto sem emitir o evento esperado.

A regra depende do contrato do produtor. Quando continuidade é obrigatória, coloque a versão 8 em espera limitada e procure a lacuna. Quando cada evento contém estado completo e a fonte autoriza avançar, a versão 8 pode substituir a anterior. Quando a consequência é sensível, bloqueie e reconcilie com a fonte oficial.

Nunca peça ao modelo para imaginar o conteúdo do evento ausente. A lacuna é um problema de estado e evidência.

Falha numa mensagem pode bloquear o grupo

Ordenação estrita cria uma consequência operacional: uma mensagem problemática pode impedir o avanço das seguintes dentro da mesma chave.

Imagine que o evento 14 contém um arquivo corrompido. Os eventos 15 e 16 chegaram corretamente. Processar 15 antes de decidir o destino de 14 pode violar a sequência. Manter 14 em retentativa infinita paralisa aquele objeto.

Defina:

quantidade e janela de tentativas;
causas recuperáveis e permanentes;
prazo máximo de bloqueio do grupo;
destino da mensagem problemática;
regra para liberar as seguintes;
estado que representa lacuna conhecida;
responsável por decidir reprocessamento ou salto;
reconciliação depois da liberação.

A fila de erros para agentes de IA ajuda a isolar unidades esgotadas. Em fluxos ordenados, mover uma mensagem para DLQ também exige decidir o que acontece com as sucessoras. Retirar o item e continuar silenciosamente pode preservar throughput e quebrar o processo.

Reentrega continua possível

Ordem e duplicidade são dimensões diferentes. Uma mensagem pode ser entregue novamente e continuar na posição correta do grupo.

Cada evento precisa de:

event_id estável;
chave idempotente para o efeito;
registro de versão aplicada;
confirmação do destino;
tratamento de resposta perdida;
política de retenção do histórico de deduplicação.

O guia de idempotência em agentes de IA cobre comando, efeito e confirmação. Em fluxo ordenado, a deduplicação também protege a sequência: uma segunda cópia da versão 4 não pode produzir uma nova consequência entre as versões 5 e 6.

Exemplo: agente de follow-up comercial

Um agente acompanha eventos de uma oportunidade.

Eventos publicados

versao 41: proposta_enviada
versao 42: cliente_respondeu
versao 43: oportunidade_ganha

A versão 41 pode criar uma espera para follow-up. A versão 42 cancela a mensagem automática e encaminha a resposta ao vendedor. A versão 43 encerra a cadência.

Evento atrasado

Depois da versão 43, uma integração republica a versão 41. O consumidor identifica a chave da oportunidade, consulta a versão atual e bloqueia a criação de nova tarefa.

Efeito confirmado

A tarefa antiga é encerrada sob condição de versão. Nenhuma comunicação é enviada. O registro mostra qual evento foi recusado e qual estado tornou a ação inválida.

Esse desenho preserva a lógica comercial. O agente não tenta interpretar se um follow-up “ainda parece útil” depois do ganho. A regra do processo encerra a possibilidade.

Exemplo: documentos que chegam em partes

Uma análise recebe três documentos do mesmo caso. A ordem entre arquivos independentes pode não importar. Já a ordem entre versões do mesmo documento importa.

Use duas dimensões:

caso_id: CASO-310
arquivo_id: CONTRATO-8
versao_arquivo: 4

Arquivos diferentes do caso podem ser extraídos em paralelo. As versões do contrato usam arquivo_id como chave e rejeitam versão anterior depois da substituição.

Quando a análise consolidada depende de todos os arquivos, crie uma etapa separada que confirma cobertura do pacote. Não transforme a fila inteira do caso numa sequência rígida apenas para saber se o conjunto ficou completo.

Métricas para operar mensagens ordenadas

Acompanhe por fila, chave e tipo de evento:

mensagens publicadas e recebidas;
atraso entre ocorrência e publicação;
atraso entre publicação e processamento;
versões antigas bloqueadas;
saltos de versão;
grupos bloqueados por falha;
idade da primeira mensagem bloqueada;
retentativas por grupo;
duplicidades identificadas;
tempo até reconciliação;
quantidade de chaves ativas;
distribuição de mensagens por chave;
throughput por grupo;
efeitos recusados no destino;
eventos aplicados fora de sequência;
consequências incorretas que escaparam.

Uma média da fila pode esconder uma única oportunidade presa há horas. Mostre o objeto, a versão esperada, a versão recebida, o dono da decisão e o prazo de tratamento.

Teste as inversões antes da produção

Monte um conjunto sintético com eventos numerados. Execute cenários como:

versões 1, 2 e 3 chegam na sequência;
versões 1, 3 e 2 chegam fora da sequência;
versão 2 chega duas vezes;
versão 4 chega sem a versão 3;
versão 2 falha permanentemente;
consumidor reinicia durante a versão 3;
confirmação da escrita se perde;
dois produtores publicam para a mesma chave;
eventos da mesma chave saem de regiões diferentes, quando o serviço condiciona a garantia à região;
uma chave concentra volume desproporcional;
o evento chega depois do prazo de negócio;
uma pessoa altera o objeto enquanto a fila processa.

Confira estado final, quantidade de efeitos, versão aceita, mensagens recusadas, evidência e tempo de recuperação. O teste passa quando o resultado empresarial permanece correto, não apenas quando o log mostra a sequência esperada.

Erros comuns

Usar uma fila FIFO global

Objetos independentes passam a esperar uns pelos outros. O sistema perde paralelismo sem ganhar uma fronteira útil de consistência.

Confiar somente no horário

Timestamp não prova sequência quando produtores, relógios e atrasos diferem. Use versão ou número emitido pela fonte que controla o objeto.

Preservar entrega e ignorar conclusão

Uma tarefa lenta pode terminar depois da seguinte. O compromisso no destino ainda precisa validar versão.

Liberar sucessoras depois da DLQ sem regra

A fila volta a andar, mas o objeto pode ficar com uma lacuna invisível. Registre a decisão e reconcilie o estado.

Retentar evento vencido

Uma versão antiga não se torna atual pela repetição. Classifique como atraso e aplique a política correspondente.

Confundir grupo de ordem com isolamento de cliente

A chave organiza sequência. Permissões, credenciais e dados continuam exigindo fronteiras próprias.

Colocar a decisão no prompt

A instrução “respeite a ordem” não substitui chave, versão, condição de escrita e bloqueio de transição inválida.

Checklist de ordenação

[ ] A unidade que exige sequência está definida?
[ ] A chave representa a menor fronteira útil?
[ ] Objetos independentes continuam paralelos?
[ ] O produtor emite versão ou sequência confiável?
[ ] A mensagem preserva origem, evento e causalidade?
[ ] O consumidor bloqueia versão antiga?
[ ] Saltos de versão possuem política explícita?
[ ] A escrita valida a versão perto do compromisso?
[ ] Reentregas usam idempotência?
[ ] Falha permanente possui destino e regra para sucessoras?
[ ] Prazo de negócio pode invalidar evento atrasado?
[ ] Métricas mostram grupos bloqueados e lacunas?
[ ] Testes cobrem inversão, duplicidade, perda e recuperação?
[ ] A garantia do serviço foi conferida para região, fila e assinatura usadas?

A sequência correta pertence ao objeto

Ordenar todas as mensagens é uma resposta cara e imprecisa. O processo precisa preservar a história dos objetos que mudam de estado e permitir que o restante avance em paralelo.

Escolha uma chave por pedido, oportunidade, caso ou documento. Carregue versão, bloqueie eventos atrasados e valide o compromisso no sistema oficial. Quando uma mensagem falhar, trate a lacuna como decisão operacional.

A fila organiza entrega. O estado do negócio decide se a mensagem ainda possui autoridade para produzir efeito.

Fontes oficiais verificadas em 25 de setembro de 2026: