Regras de consistência

Estas cinco regras garantem que o CRM fique igual ao seu sistema mesmo com rede instável, reenvio e eventos chegando fora de ordem.

1. Envie o estado completo, não só o que mudou#

Se o valor mudou, envie o orçamento inteiro com o valor novo, e não só o campo alterado. Cada evento substitui o estado anterior por completo. Assim, receber o mesmo evento duas vezes, ou perder um no meio do caminho, não deixa o dado errado: o próximo envio corrige.

2. occurredAt decide a ordem#

Um evento com occurredAt igual ou anterior ao último aplicado naquele orçamento é ignorado. Isso protege contra entregas fora de ordem: um "perdido" antigo que chega atrasado não desfaz um "pago" mais novo.

• Use o horário real da mudança no seu sistema, não o horário do envio.
• Envie sempre com fuso horário.
• Datas mais de 5 minutos no futuro são recusadas (occurredAt_in_future). Um relógio adiantado congelaria o orçamento.

3. id identifica o conteúdo#

• Reenviar o mesmo evento (mesmo id, mesmo corpo) é seguro: volta duplicate e nada muda.
• Reusar um id com corpo diferente volta rejected com id_reused. Toda mudança precisa de um id novo.

Uma forma simples de gerar o id: combinar o id do orçamento com a data da alteração, por exemplo orc_991:2026-10-07T13:00:00-03:00.

4. Reenvie com os mesmos ids#

Em erro de rede, timeout, 429 ou 5xx, reenvie o lote inteiro com os mesmos ids. O que já tinha entrado volta como duplicate; o resto entra normalmente. Use espera crescente entre as tentativas (1 s, 2 s, 4 s...).

5. Exclusão é definitiva para eventos antigos#

Depois de um deal.deleted, eventos mais antigos daquele orçamento são ignorados. Um deal.upserted mais novo reativa o orçamento, caso ele volte a existir no seu sistema.