Pular para conteúdo

Propostas — Consistência Transacional no Atendimento (CRM Legado / ATD)

Projeto: DSB26201 · Assessment de Arquitetura e Integrações · Energisa Elaborado por: Syntropy Labs (Castellani) Status: Brainstorming de consultoria — não é achado confirmado nem arquitetura To-Be oficial

Aviso metodológico

Estas propostas nasceram de discussões técnicas de consultoria sobre o achado já documentado na Ata 09 (010-evidencias/090-canais-digitais-atendimento.md) e no risco R08 (dual write sem Outbox, matriz-riscos-consolidada.md) — não de uma sessão nova com a Energisa. Por isso vivem em 030-artefatos/, fora de 100-to-be/: pelo plano de trabalho, a arquitetura alvo (Fase 4) só vira base oficial depois da validação de Fase 3 com Norberto e Rômulo, seguida da rodada técnica com as áreas — validação que ainda não ocorreu. Mesmo racional já aplicado em propostas-wfm-eforce/, propostas-engenharia-dados/ e propostas-barramento-ksqldb/.

Diferença em relação às demais pastas de propostas deste repositório: nenhuma das duas parte de uma ideia inteiramente nova.

  • Proposta 1 operacionaliza uma ação já acordada pela própria Energisa na Ata 09, item 1.10.19 (plano de ação, item 10): "Avaliar e prototipar o padrão Outbox nos pontos de dual write". O time do atendimento e dos canais digitais já reconheceu o padrão Transactional Outbox como estratégia adequada (item 1.10.17.7 da Ata) — o que faltava era a decisão de qual mecanismo de captura usar entre a tabela de outbox e o Kafka, que é o que a Proposta 1 endereça (captura via XStream customizado).
  • Proposta 2 formaliza uma regra de triagem que o próprio Castellani já propôs em sessão real com a Energisa (24/07/2026, ainda sem Ata formal, ver fluxos-atendimento-adms.md linha 444), endossada informalmente por Norberto: eventos ponto-a-ponto dentro do mesmo domínio não precisam do Kafka corporativo — Oracle AQ/TxEventQ resolve com atomicidade nativa e menos esforço. Aplica essa regra a um hop específico do mesmo fluxo da Proposta 1, eliminando outbox e CDC por completo onde a regra se confirma.

As duas propostas são alternativas mutuamente exclusivas para o mesmo hop (MsAttOcorrenciaTecnica → MsCrmMiddleware, tópico crm_registra_ocorrencia_sistema_tecnico), não complementares — a escolha entre elas depende de uma confirmação de fato ainda pendente (se o tópico é hoje estritamente ponto-a-ponto) e de uma decisão arquitetural (privilegiar menor esforço vs. manter consistência com o barramento corporativo único). Ver a seção "Riscos e ressalvas" de cada uma.

Nenhuma das duas foi validada com a Energisa. São primeiras formulações técnicas, com trade-offs explícitos e riscos deliberadamente não escondidos.

As propostas

# Proposta Resolve Não resolve
1 Transactional Outbox + captura XStream customizada Dual write entre a base ATD (Oracle 19) e o Kafka nos microsserviços de ocorrência técnica (R08), mantendo o Kafka como barramento O mesmo problema do lado do Sigode (MongoDB) — mecanismo de captura diferente, fora de escopo aqui; qualquer lógica de negócio dos microsserviços além da publicação em si
2 Oracle AQ ponto-a-ponto (sem Kafka, sem CDC) O mesmo dual write, restrito ao hop MsAttOcorrenciaTecnica → MsCrmMiddleware, com esforço de engenharia menor — condicionado à confirmação de que o tópico é estritamente 1:1 Os demais hops do fluxo (ex.: WSROT → MsAttOcorrenciaTecnica, que cruza fronteira de domínio); o lado Sigode/MongoDB

Evidência que motivou a proposta

Ata 09 (sessões de 15 e 16/07/2026) identifica dual write como um dos três temas centrais de risco do ecossistema de atendimento, com incidente real já ocorrido: uma ocorrência cancelada no DMS não teve o cancelamento propagado ao Sigode, exigindo carga manual de dados para restabelecer a consistência (item 1.10.6.6). O mesmo padrão de dual write existe nos microsserviços que gravam na base ATD (Oracle 19, confirmado no item 1.10.14.1) — MsAttOcorrenciaTecnica, MsAttComunicacao, MsAttDesligamentoEmergencial — com uma mitigação parcial e frágil já aplicada em um deles (inversão da ordem de confirmação entre banco e barramento, item 1.10.6.3), que reduz mas não elimina a janela de inconsistência.

Ver também