Mensageria — requisitos para a plataforma

A frase canônica acima vale sem exceção de mecanismo. Todo evento de domínio é publicado depois do commit da unidade de trabalho que o produziu. Rollback não publica nada. Falha de consumidor não desfaz o ato nem volta ao chamador como erro. Nenhum consumidor produz efeito de que o ato dependa — a única exceção declarada é a A1.7.

Por quê: publicar antes do commit avisa decisão que reverteu e alonga a trava da aprovação · Aceite: CA-01 a CA-04 · Evidência: E-01

O evento é registrado atomicamente com o commit do ato — os dois existem, ou nenhum. A entrega é pelo menos uma vez, e todo consumidor é idempotente por um identificador estável da mensagem. Nova tentativa transitória não perde evento: se a gravação é repetida pela estratégia de execução, os eventos coletados na primeira tentativa continuam lá. Queda do processo entre o commit e a entrega não perde a mensagem. Vale igual para aviso imediato e aviso agendado: reinício não apaga, réplica não duplica.

Por quê: com dois processos e réplicas, o que está só em memória some no reinício e sai n vezes · Aceite: CA-05 a CA-09 · Evidência: E-02, E-05, E-06

Todo consumidor e todo job executam com o tenant capturado no registro da mensagem ou no enfileiramento, e restaurado na execução. Leitura de dado de tenant sem tenant em vigor não devolve nada ou falha — nunca devolve os dados de todos os tenants —, e esse é o comportamento padrão de todo host, não uma opção a ligar. Varredura que precisa enxergar todos os tenants desliga o filtro explicitamente e processa cada item com o tenant dele. O usuário que causou o fato viaja como dado, para a trilha; nunca como identidade autenticada. Nenhum job executa comando em nome de usuário na v1.

Por quê: o filtro de tenant é a última defesa entre clientes, e hoje libera tudo quando falta contexto · Aceite: CA-10 a CA-13 · Evidência: E-03, E-04, E-07, E-14

Ordem é garantida somente dentro de uma chave declarada, e só para os tipos de mensagem que a declaram. Na v1 o único caso é o pacote de integração com o ERP, com chave no documento de origem. Dentro da chave, mensagem que falhou e aguarda nova tentativa, ou que esgotou as tentativas, não é ultrapassada por outra da mesma chave: a chave para, com alerta, até a da frente sair ou ser tratada por pessoa. Entre chaves não há ordem, e uma chave parada não segura as outras. Caso novo de ordem entra com a chave declarada na página dona.

Por quê: um cancelamento que chega ao ERP antes da criação deixa o pedido vivo lá; ordem global serializaria o sistema para resolver um caso · Aceite: CA-14 a CA-16 · Evidência: E-08

Condição de negócio que impede a saída não descarta a mensagem nem deixa de produzi-la. O caso de uso escolhe o dado utilizável — na carência de conta bancária, a conta anterior, que continua vigente e pagável durante a janela (ver Fornecedor) — e só quando não há dado utilizável a mensagem fica aguardando, com motivo e condição de liberação, e sai sozinha quando a condição se resolve. Mensagem que esgotou as tentativas fica visível e parada, com alerta; reprocessar ou descartar é ato de pessoa, com permissão própria, motivo obrigatório no descarte e registro de quem fez. Expurgo só alcança mensagem entregue. O mesmo vale para a repetição, depois do commit, de ato de pessoa — a guarda legal e a eliminação do Anexo repetidas no arquivo, com o autor do ato viajando como dado e gravado no destino marcado como declarado, com o executor de serviço, nunca como usuário autenticado nem como o job: recusa transitória do destino, como a trilha durável indisponível, deixa a repetição aguardando com o motivo, nunca descartada e nunca dada por concluída sem o efeito. Recusa definitiva do destino não pode chegar depois de o ato irreversível ter sido gravado e publicado: o consumidor pergunta ao destino, antes de gravar, a mesma pré-condição que o destino conferirá — consulta sem efeito, com a mesma resposta — e recusa o ato na hora. Mas conferir antes não basta: consulta que não reserva precisa de trava comum com o efeito que ela prevê — a conferência e o efeito disputam o mesmo registro —, senão o consumidor publica sobre um retrato já vencido; o que muda entre a consulta e a repetição fica visível como bloqueado, com código estável que o consumidor grava e mostra, nunca como concluído.

Por quê: pedido aprovado que nunca chega ao ERP, sem erro e sem estado, é descoberto pelo fornecedor que não recebeu · Aceite: CA-17 a CA-19 · Evidência: E-09

Todo efeito em sistema externo carrega a chave natural do documento do Nexio e grava o ExternalRef devolvido. Reentrega não cria segundo pedido nem segundo pagamento: o adaptador usa a chave de idempotência do destino quando ele oferece, e consulta pela chave natural antes de criar quando não oferece. Efeito externo de desfecho incerto — o processo caiu durante o envio — não é reenviado às cegas: vai para conciliação pela chave natural.

Por quê: “pelo menos uma vez” até o ERP, sem isso, é risco de pedido e pagamento em dobro · Aceite: CA-20, CA-21 · Evidência: E-10

Revogar papel ou permissão de um usuário incrementa a versão do token (TokenVersion) na mesma transação da revogação — é a exceção declarada à regra de que reação vem depois do commit. Propagar a revogação para cache ou lista de bloqueio pode ser posterior; a fonte da verdade, não. Depois do commit, o token antigo é recusado mesmo que nenhum consumidor tenha rodado.

Por quê: controle de acesso não se aproxima — se a invalidação for reação e a reação falhar, quem perdeu o acesso continua com ele · Aceite: CA-22 a CA-24 · Evidência: E-11

A solução não pode eliminar o degrau 4 da escada de escala — instância por contexto: um contexto do mesmo tenant em instância de banco própria. Todo banco onde uma mensagem pode ser registrada tem entrega; nenhum fica sem quem o drene. Se a solução exigir uma conexão só por tenant, o estudo registra essa decisão na Arquitetura antes da adoção, revogando o degrau 4 de forma explícita — nunca por efeito colateral.

Por quê: o degrau 4 é a saída de escala mais barata que a fronteira do ADR 1 comprou, e a mudança atinge todos os produtos do Gryd.IO · Aceite: CA-25 · Evidência: E-12

Restrição do estudo. Nenhuma peça nova para o time operar além dos serviços gerenciados do ADR 7 — ou, havendo, o custo em horas por mês declarado. Uma consulta só responde “o que está aguardando, em falha e parado”, por tenant e por tipo, com a idade da mais antiga como sinal de saúde. Os critérios de aceite desta página rodam automatizados contra o banco real na suíte da plataforma.

Por quê: duas respostas para “o que está preso” é um operador cruzando dois sistemas por cliente, com centenas de clientes · Aceite: CA-26, CA-27 · Evidência: E-13