A escolha que, na verdade, não é sobre tecnologia
Quando uma organização começa a discutir Arquitetura Orientada a Eventos no Salesforce, a conversa tende a se inclinar rapidamente para "Platform Events ou CDC?", como se fosse puramente uma questão de ferramenta. No entanto, o cerne da questão é completamente diferente: que lado da integração é a fonte da verdade, o que pode ser perdido, e quem arca com o custo quando uma mensagem chega atrasada, em duplicidade ou não chega de todo.
A resposta concisa: Change Data Capture (CDC) é adequado quando um sistema externo precisa saber que o Salesforce atualizou um registro, e isso não exige o encapsulamento de lógica de negócios. Platform Events personalizados são ideais quando se deseja publicar um evento de negócios significativo – "cliente fez upgrade de plano", não "o campo Status__c foi alterado". A escolha inadequada não se manifesta no dia do lançamento; ela se revela quando alguém precisa reconstruir o que aconteceu após uma falha parcial, e descobre que não há um caminho confiável para obter essa informação.
Aqueles que buscam uma visão mais abrangente das integrações Salesforce além dos eventos encontrarão informações úteis no Guia de Arquitetura de CRM.
Três perguntas que definem a arquitetura antes de escrever uma linha de código
Antes de selecionar um mecanismo, três perguntas precisam ser respondidas. Pular qualquer uma delas é a causa mais comum de projetos de integração que empacam na fase de testes.
Quem é o proprietário dos dados? Se o Salesforce é a fonte da verdade para o registro do cliente, eventos de saída do Salesforce (Platform Event ou CDC) são a direção natural. Se o sistema ERP é o proprietário, a direção oposta é verdadeira, e o Salesforce precisa consumir eventos, e não publicá-los, para a mesma entidade.
O que pode ser perdido? Um alerta para um dashboard gerencial pode perder uma única mensagem sem prejuízos. A atualização de um limite de crédito antes da aprovação de uma transação não pode. Essa distinção determina se basta um modelo "fire-and-forget" ou se é necessário um mecanismo de confirmação e monitoramento de divergências (Reconciliation).
O que acontece se a mensagem chegar duas vezes? Platform Events garantem "At-Least-Once", e não "Exactly-Once". Se a resposta for "não sabemos", a solução ainda não está pronta para produção, independentemente da qualidade do código.
Platform Events vs. CDC — Tabela de Decisão
| Critério | Platform Event Personalizado | Change Data Capture |
|---|---|---|
| O que é publicado | Evento de negócio definido (Payload personalizado) | Alteração bruta de registro (Antes/Depois) |
| Quem constrói a lógica | Desenvolvedor Salesforce, no Trigger ou Flow | A plataforma, automaticamente para qualquer DML configurado |
| Acoplamento ao esquema | Baixo — Payload controlado pelo publicador | Alto — Toda alteração na estrutura do objeto afeta o consumidor |
| Adequado quando... | Se deseja publicar uma intenção de negócio ("Pedido Aprovado") | Se deseja sincronização de dados brutos entre sistemas |
| Custo de manutenção | Mais alto inicialmente (construção de Payload e lógica) | Baixo inicialmente, alto quando a estrutura do objeto muda |
| Retention | Conforme definição da licença (horas a dias) | Conforme definição da licença, geralmente o mesmo que Platform Events |
| Volume recomendado | Eventos de domínio de frequência média | Alterações em nível de registro, incluindo alta frequência |
A regra prática: se o consumidor do evento precisa entender "por que" isso aconteceu e não apenas "o que" aconteceu, um Platform Event personalizado é necessário. Se o consumidor apenas precisa de uma cópia atualizada dos dados, o CDC economiza uma camada completa de desenvolvimento.
Ordering, Replay e Idempotency: Os três conceitos que transformam teoria em produção estável
Estes não são temas para a fase tardia do projeto – eles definem a estrutura do consumidor desde o primeiro dia.
Ordering. Platform Events são enviados na ordem de publicação dentro do mesmo tópico, mas a carga e falhas parciais podem perturbar a ordem de recebimento no lado do consumidor. Solução prática: anexar um carimbo de versão ou número de sequência (Sequence Number) do registro original a cada evento, e permitir que o consumidor rejeite eventos cuja versão seja inferior à última versão já processada.
Replay. Cada evento recebe um Replay ID. Um consumidor que falha deve salvar o último Replay ID que processou com sucesso – não na memória, mas em um local durável (Custom Object, tabela externa) – e continuar a partir daí com a recuperação. A dependência de "o sistema começará do zero" só funciona dentro da janela de Retention, e além dela, os eventos são perdidos.
Idempotency. Todo consumidor deve identificar um evento que já foi processado, geralmente por meio de um identificador de transação único enviado no Payload. Sem isso, um Retry automático por parte do remetente – ou um Replay manual após uma falha – resulta em uma atualização duplicada, criação de registro duplicado ou, no pior cenário, uma cobrança duplicada.
Essa lacuna quase nunca é descoberta na demonstração. Ela aparece sob carga, em uma falha de rede real ou em uma mudança no ambiente de produção, e então o custo para corrigi-la já inclui também a correção de dados. Organizações que enfrentam um problema semelhante na camada de automação encontram uma análise complementar em Dívida Técnica no Salesforce com Flow e Apex.
Cenário de exemplo: Uma rede de varejo com 40 filiais e um sistema de estoque separado
Considere uma rede de varejo hipotética, "Varejo do Norte", que opera Salesforce Sales Cloud para equipes de vendas em 40 filiais e um sistema ERP separado que gerencia o estoque em tempo real. Até então, cada pedido fechado no Salesforce era transferido para o ERP por meio de um Job agendado que rodava a cada 15 minutos, uma solução que ocasionalmente fazia com que os representantes vissem estoque desatualizado e aprovassem pedidos para produtos esgotados.
A equipe de arquitetura decidiu publicar um Platform Event personalizado chamado Order_Confirmed__e a cada confirmação de pedido, com um Payload que incluía um identificador de transação único, lista de itens e quantidades. O ERP escuta o evento e atualiza o estoque em segundos, verificando o identificador da transação em uma tabela de transações já processadas para evitar deduções duplicadas caso o evento chegasse duas vezes.
Além disso, foi definido um processo de Reconciliação noturno que compara o total de pedidos aprovados no Salesforce com o total de atualizações recebidas no ERP, alertando sobre uma divergência acima de um limite definido. A razão: mesmo com Idempotency adequado, desejava-se a detecção precoce de uma falha de rede prolongada, e não apenas a dependência de que o evento "certamente chegou". O resultado: o tempo de atualização caiu de 15 minutos para menos de um minuto, e o número de eventos de estoque incorretos diminuiu de forma mensurável em um mês após a implementação.
O cenário ilustra um princípio central: o valor não é gerado pela "passagem de eventos" por si mesma, mas pela combinação de um evento de negócios claro, verificação de duplicidade no lado do consumidor e um processo de monitoramento que identifica divergências antes que se tornem uma reclamação do cliente.
Riscos comuns e ações preventivas
| Risco | Como se manifesta na prática | Ação preventiva |
|---|---|---|
| Publicação de evento a cada alteração de campo | O limite diário de eventos é excedido em poucos dias | Publicar eventos de Dominio com significado de negócio, não um evento técnico a cada DML |
| Ausência de verificação de duplicidade no consumidor | Retry ou Replay criam registros ou atualizações duplicadas | Anexar um identificador de transação único e verificá-lo antes de cada operação |
| Dependência da ordem de chegada | Uma atualização antiga sobrescreve uma atualização mais recente | Anexar um carimbo de versão e rejeitar eventos antigos em relação à última versão processada |
| Ausência de salvamento do Replay ID | Após uma falha do consumidor, eventos entre a falha e a janela de Retention são perdidos | Salvar o Replay ID em um local durável e executar Replay automático ao reiniciar |
| CDC em objeto cuja estrutura muda frequentemente | Qualquer alteração de campo quebra o consumidor externo sem aviso | Definir um contrato de dados explícito e comunicar mudanças de esquema antecipadamente |
| Ausência de monitoramento de negócio, apenas técnico | A integração está "verde", mas o estoque ou pedidos reais não correspondem | Adicionar Reconciliação diária que compare o resultado de negócio entre os sistemas |
Checklist antes de iniciar o desenvolvimento da camada de eventos
- ☐ Cada evento possui um proprietário claro: quem publica e quem é o proprietário de negócio dos dados
- ☐ Um Payload fixo e documentado foi definido, não uma estrutura que muda a cada Sprint
- ☐ A escolha entre Platform Event personalizado e CDC foi feita com base na intenção de negócio versus alteração bruta
- ☐ Cada consumidor possui um identificador de transação único e verificação de duplicidade (Idempotency)
- ☐ O tratamento da ordem é definido por carimbo de versão, não por ordem de chegada
- ☐ O Replay ID é salvo em um local durável e o processo de recuperação é definido e testado
- ☐ Existe monitoramento de negócio (Reconciliação) além do monitoramento técnico da fila de mensagens
- ☐ O cenário de carga e o cenário de falha parcial foram testados, não apenas o Happy Path
- ☐ O limite diário de eventos (Publicação + Entrega) foi verificado contra o volume esperado em produção
- ☐ Um Owner operacional foi definido para responder quando uma divergência for detectada na Reconciliação
Como medir a eficácia da arquitetura
| Área | O que medir | Frequência de verificação |
|---|---|---|
| Confiabilidade da entrega | Percentual de eventos concluídos sem Retry, e percentual bem-sucedido após Retry | Contínuo |
| Divergências de Reconciliação | Diferença entre registros confirmados na origem e recebidos no destino | Diário |
| Latência ponta a ponta | Tempo entre o evento de negócio e a atualização real no consumidor | Contínuo |
| Utilização do limite de eventos | Percentual da cota diária realmente utilizada | Semanal |
| Duplicidades evitadas | Número de eventos identificados como duplicados e bloqueados antes da execução | Semanal |
Recomenda-se selecionar não mais do que três a quatro métricas para a primeira versão, e medi-las contra uma linha de base (Baseline) coletada antes da transição para a arquitetura de eventos – não contra uma percepção geral de que "agora está mais rápido".
Para o planejamento de uma estrutura organizacional mais ampla com múltiplas integrações, é útil examinar também os Padrões de Integração do Salesforce e as implicações para a Arquitetura de Single Org versus Multi Org do Salesforce, pois a decisão sobre eventos pode, às vezes, transcender os limites organizacionais.
Resumo
A escolha entre Platform Events e CDC não é uma questão técnica a ser analisada brevemente no início de um projeto – ela define quem é a fonte da verdade, o que pode ser perdido e como o sistema se comporta quando algo falha no meio do processo. Uma organização que planeja antecipadamente Ordering, Replay e Idempotency, e adiciona uma camada de Reconciliação de negócio, e não apenas monitoramento técnico, obtém uma integração que suporta carga e falhas parciais. Uma organização que pula essas etapas obtém um sistema que parece funcional nos testes, mas falha silenciosamente em produção, geralmente sem que ninguém perceba até que o dano já tenha ocorrido.
Organizações que buscam suporte na construção de uma camada de eventos confiável no Salesforce podem entrar em contato através do serviço de arquitetura de CRM.