Salesforce entrega quatro formas distintas de empurrar eventos para fora da plataforma. Elas parecem similares em um slide e se comportam de forma muito diferente em produção. Escolher a errada é o tipo de decisão que você só percebe seis meses depois, quando o volume é alto o suficiente para expor o contrato que você não leu com atenção.
A Parte 1 desta série cobriu as arestas operacionais específicas de Platform Events. Essa parte dá um passo atrás: como você decide entre CDC, Platform Events, Pub/Sub API (no que a Streaming API se transformou) e Outbound Messaging, antes de qualquer linha de código?
A resposta curta: não existe um "melhor" universal. Cada mecanismo garante uma coisa diferente. Combine a garantia ao requisito.
Os Quatro Mecanismos e o Que Eles Realmente Garantem
Antes da matriz de decisão, os contratos. Leia com atenção — a maioria das decisões arquiteturais ruins nesse espaço vem de pular essa etapa.
Change Data Capture (CDC)
O que é: Salesforce publica um evento automaticamente sempre que um registro em um objeto habilitado muda. Zero código no publisher. O payload do evento inclui os campos alterados, o tipo de mudança (CREATE/UPDATE/DELETE/UNDELETE), e um ChangeEventHeader com metadados (recordIds, changeOrigin, transactionKey, sequenceNumber).
O que garante:
- Somente mudanças commitadas são publicadas — uma transação revertida não gera evento
- Eventos para o mesmo registro chegam na ordem da transação, com escopo em
transactionKey+sequenceNumber - Retenção de 72 horas no event bus com semântica de
ReplayIdidêntica à de Platform Events - Visibilidade em nível de campo — você vê exatamente quais campos mudaram e os novos valores
O que não garante:
- Ordenação global entre registros diferentes. Duas atualizações em duas Contas diferentes não têm ordem definida uma em relação à outra.
- Entrega em uma janela de tempo específica. CDC é async — latência típica é de segundos, mas não há SLA.
- Cobertura de todos os tipos de campo. Long text areas, campos criptografados e alguns campos padrão são excluídos do payload.
Cota diária de entrega: baseada na edição. Enterprise Edition começa com 250.000 eventos/dia compartilhados entre CDC e Platform Events somados; é possível comprar mais via SKU add-on.
Platform Events
O que é: Um canal de evento custom. Você define o schema (objeto de evento custom terminando em __e), publica de Apex / Flow / Pub/Sub API, assina de triggers / Flows / clientes externos.
O que garante:
- Fan-out pub/sub — múltiplos subscribers recebem o mesmo evento de forma independente
- Retenção de 72 horas com
ReplayId - Dois comportamentos de publicação: Publish After Commit (evento dispara só se a transação ao redor commitar) e Publish Immediate (dispara independente do resultado da transação — útil para log de erros, perigoso para sinais de mudança de estado)
O que não garante:
- Ordenação, nem dentro de um único canal. A Parte 1 cobriu isso em detalhe.
- Que o evento será entregue — floods em alto volume podem causar enfileiramento silencioso depois do teto horário de entrega (250k/hora padrão).
- Consistência transacional, exceto se você usar Publish After Commit.
Pub/Sub API (anteriormente Streaming API)
O que é: Uma API gRPC bidirecional de streaming para publicar e assinar Platform Events e eventos CDC a partir de sistemas externos. Substitui a Streaming API baseada em CometD e o mecanismo PushTopic (depreciado).
Status no release Spring '26: a Pub/Sub API é o único caminho suportado para novos subscribers externos. CometD continua disponível mas em modo de manutenção — sem novas features, timeline de depreciação em discussão ativa.
O que garante:
- Protocolo binário eficiente (payloads codificados em Avro, multiplexação HTTP/2) — overhead significativamente menor que o long-polling HTTP do CometD legado
- Controle de fluxo — subscribers solicitam um número específico de eventos via
FetchRequest, o servidor não envia além disso - Replay a partir de um
ReplayIdespecífico ou deLATEST/EARLIEST - Mesma retenção de 72 horas do event bus subjacente
O que não garante:
- Não é um mecanismo de evento separado — é um protocolo de acesso para os mesmos Platform Events e eventos CDC. As características de ordenação e entrega desses eventos subjacentes continuam valendo.
Isso é importante e rotineiramente confundido: "devemos usar Pub/Sub API ou Platform Events?" é uma pergunta mal formada. Você publica um Platform Event; um sistema externo o consome via Pub/Sub API. Eles são empilhados, não alternativas.
Outbound Messaging
O que é: Uma ação de workflow / Flow que faz POST de um envelope SOAP para um endpoint HTTPS externo quando um registro muda.
O que garante:
- Retry embutido com backoff exponencial — Salesforce continua tentando por 24 horas até o endpoint retornar um acknowledgment SOAP
- Entrega garantida dentro dessas 24 horas se o endpoint voltar a responder
- Ordenação preservada por workflow rule (entrega sequencial)
- Zero código de subscriber no lado Salesforce
- Configurável pelo Setup / Flow sem escrever Apex
O que não garante:
- Um formato de dado moderno. O payload é SOAP/XML. Não há suporte para JSON, gRPC, ou qualquer formato binário.
- Nada além de point-to-point simples. Não há pub/sub — cada endpoint é configurado individualmente.
- Compatibilidade com API gateways modernos. Endpoints SOAP com o formato de envelope estrito que o Salesforce espera estão cada vez mais raros de manter em produção.
É o mecanismo mais antigo da lista. Também é o mais confiável operacionalmente para o caso de uso restrito que ele cobre.
A Matriz de Decisão
As linhas abaixo são os requisitos que realmente determinam a escolha certa; as colunas são os quatro mecanismos. Identifique as linhas que são requisitos inegociáveis no seu caso e escolha a coluna que responde "Sim" a todos eles — o mecanismo cuja coluna atende às suas exigências é o que vai para produção.
| Requisito | CDC | Platform Events | Pub/Sub API | Outbound Messaging |
|---|---|---|---|---|
| Ordenação estrita por registro | Sim (por registro, por transação) | Não | Herda do evento subjacente | Sim (por regra, sequencial) |
| Volume > 50k eventos/hora sustentado | Sim (com compra de cota) | Sim (com cota) | Sim (projetada para isso) | Não (gargalo de entrega sequencial) |
| Subscriber externo | Sim (via Pub/Sub API) | Sim (via Pub/Sub API) | Sim (é o protocolo) | Sim (é a única opção) |
| Rastreamento em nível de campo | Sim (header changedFields) | Não (você define o schema) | Herda do evento subjacente | Apenas campos mapeados na mensagem |
| Zero código no publisher | Sim (auto-publicado no commit) | Não (Apex/Flow publica) | Não (você publica via gRPC) | Sim (Workflow/Flow action) |
| Consistência transacional com commit | Sim (sempre pós-commit) | Opt-in (Publish After Commit) | Herda do evento subjacente | Sim (pós-commit) |
| Múltiplos consumers independentes | Sim (assinar por canal) | Sim (fan-out nativo) | Sim | Não (um endpoint por config) |
| Schema de payload custom | Não (Salesforce define) | Sim (você define campos __e) | Herda | Limitado (apenas campos mapeados) |
Algumas notas sobre como ler isso:
- "Sim" não significa "bom fit" — significa "o mecanismo suporta". Uma linha com vários "Sim" ainda exige checar o resto do contrato.
- As linhas da Pub/Sub API dizem "herda" na maioria porque é um transporte, não uma fonte de evento. Use a linha de Platform Events ou CDC dependendo do que você está publicando.
- A linha "zero código no publisher" é onde CDC e Outbound Messaging brilham. Se o requisito é "reagir a mudanças de registro sem escrever Apex no publisher", esses dois são as únicas opções.
Modos de Falha Quando Você Escolhe Errado
Cada mecanismo tem uma forma característica de falhar quando mal aplicado. Reconhecer esses post-mortems evita que você os repita.
Platform Events usado onde CDC era a resposta certa
Sintoma: você escreveu um Apex trigger em cada objeto padrão que a integração precisa, cada trigger publica um Platform Event com o registro alterado. Seis meses depois, o código dos triggers tem 1.500 linhas, cada novo campo adicionado a esses objetos exige atualizar o trigger, e o time de integração reclama que algumas mudanças passam despercebidas (porque alguém usou Data Loader com o campo de bypass marcado).
Fix: use CDC. O código do publisher some. O ChangeEventHeader já inclui os campos alterados. Cargas em massa não conseguem driblar isso porque a plataforma publica os eventos, não o Apex.
Quando a armadilha pega você: você começou com um objeto e Platform Events parecia mais simples. Depois o requisito expandiu para dez objetos.
CDC usado onde Platform Events era a resposta certa
Sintoma: você ligou CDC em Order__c porque queria disparar um workflow downstream quando pedidos completassem. Agora seu subscriber recebe um evento para cada mudança de campo em cada pedido — incluindo 50 atualizações de status por pedido ao longo do ciclo de vida, mais mudanças de operações internas de vendas que não têm nada a ver com o workflow downstream. O subscriber filtra a maioria dos eventos e você queimou 80% da cota diária de CDC até as 10h.
Fix: use Platform Events com um schema custom Order_Completed__e. O publisher dispara exatamente um evento por conclusão. Uso de cota cai 50x. O workflow downstream não precisa de lógica de filtragem.
Quando a armadilha pega você: CDC virou o default porque não exigia código no publisher. O requisito real era um evento semântico ("esse pedido terminou"), não um evento técnico ("esse registro mudou").
Outbound Messaging usado onde Platform Events era a resposta certa
Sintoma: você configurou Outbound Messaging para o endpoint SOAP de um microserviço. Depois um segundo microserviço precisa do mesmo evento. Você adiciona uma segunda regra de Outbound Message. Depois uma terceira. Agora cinco regras disparam na mesma mudança de registro, as URLs dos endpoints são gerenciadas no Setup fora de controle de versão, e rotacionar a auth em um endpoint levou duas horas clicando em telas de configuração.
Fix: publique um Platform Event uma vez. Cada microserviço assina via Pub/Sub API. Configuração do endpoint vive em cada microserviço. A fonte do evento tem uma única regra.
Quando a armadilha pega você: originalmente havia apenas um consumer, e Outbound Messaging foi o caminho de menor resistência porque dispensava Apex.
Pub/Sub API tratada como mecanismo de evento separado
Sintoma: um arquiteto especificou "vamos usar Pub/Sub API para a integração" sem dizer se estava consumindo Platform Events ou CDC. O time de dev escolhe Platform Events porque foi o que o time publisher já usou. Seis meses depois, o requisito de rastrear mudanças em nível de campo não pode ser atendido — porque Platform Events não expõe campos alterados e o publisher teria que reimplementar a lógica de diff.
Fix: nomeie explicitamente o tipo de evento subjacente na decisão de arquitetura. Pub/Sub API é como o sistema externo conversa com o bus; CDC vs Platform Events é o que está no bus.
Quando a armadilha pega você: qualquer conversa que diga "Pub/Sub API" sem imediatamente seguir com "para eventos CDC" ou "para Platform Events".
Outbound Messaging no caminho crítico de um fluxo síncrono do usuário
Sintoma: o usuário clica em "Enviar" no Salesforce, Outbound Messaging dispara para uma API externa, e o usuário espera a resposta em segundos. Às vezes funciona. Às vezes a API externa está lenta, Outbound Messaging espera até o timeout, faz retry, e o usuário já recarregou e tentou de novo — criando estado duplicado downstream.
Fix: Outbound Messaging é assíncrono por design. Se você precisa de resposta síncrona em ação do usuário, use um callout Apex de um controller ou uma Flow Action com HTTP-callout. Use Outbound Messaging só quando fire-and-forget com entrega eventual em 24 horas for aceitável.
Quando a armadilha pega você: o requisito original era async-OK, mas um requisito posterior de UX tornou o fluxo síncrono e ninguém reavaliou o mecanismo de integração.
Três Cenários Concretos
A matriz de decisão é abstrata. Três situações reais para tornar isso tangível.
Cenário 1: Sincronizar mudanças commitadas de Opportunity para um data warehouse
Requisito: toda mudança commitada em Opportunity (insert/update/delete, todos os campos) precisa chegar no Snowflake em até 5 minutos. O time do warehouse é dono do consumer. Sem lógica de negócio no lado Salesforce.
Escolha: CDC + Pub/Sub API. O serviço de ingestão do lado Snowflake assina via Pub/Sub API e lê OpportunityChangeEvent. Zero código no publisher do lado Salesforce. O header changedFields permite que o time do warehouse faça delta merges de forma eficiente. O buffer de replay cobre qualquer downtime do consumer em até 72 horas.
Por que não Platform Events: o time teria que escrever um trigger em Opportunity para publicar, implementar à mão a lógica de campos alterados, e mantê-la conforme o schema evolui. Sem upside.
Por que não Outbound Messaging: formato SOAP/XML é inviável para um pipeline de dados moderno. Além disso, configuração de endpoint único não escala se o time depois adicionar um segundo consumer.
Cenário 2: Notificar três microserviços internos quando um pedido completa
Requisito: quando um Order__c alcança status "Completed", três serviços internos precisam agir — verificação de fraude (quase síncrono, sensível à latência), reserva de estoque (SLA médio), sync com ERP (long-running). Salesforce não deve conhecer nenhum deles pelo nome.
Escolha: Platform Event (Order_Completed__e) publicado de um Apex trigger que dispara quando o status transiciona para Completed. Três subscribers independentes via Pub/Sub API, cada um com sua própria semântica de backpressure e replay. Publish After Commit em Apex garante que o evento dispara só em commit bem-sucedido.
Por que não CDC: o requisito é um evento semântico ("completed"), não um evento de mudança de registro. CDC dispararia em cada update de status e em cada outra mudança de campo, exigindo filtragem downstream e queimando cota.
Por que não Outbound Messaging: três endpoints significam três regras de Outbound Message com três configs separadas. Coordenação entre times vira sofrimento.
Cenário 3: Empurrar resultado de aprovação para um sistema SOAP on-prem legado
Requisito: um Flow de aprovação custom completa e o resultado precisa ser enviado por POST para um sistema de compras legado. O sistema de compras só fala SOAP e está atrás de um firewall corporativo. Confiabilidade importa mais que latência — entrega no mesmo dia é aceitável.
Escolha: Outbound Messaging. Zero código de subscriber em qualquer lado. Envelope SOAP é o que o sistema legado espera. Retry embutido de 24 horas lida com indisponibilidades transitórias do firewall sem código custom. O fato de ser tecnologia antiga combina com o sistema com quem está conversando.
Por que não Platform Events: um consumer SOAP externo de um Platform Event exigiria construir uma ponte (cliente Pub/Sub API → transformador SOAP → sistema de compras). Centenas de linhas de código e um serviço adicional para operar, substituindo algo que entrega o mesmo resultado em três cliques.
Por que não CDC: o evento gatilho é "resultado de aprovação", não "registro mudou".
Heurísticas de Decisão
Um checklist curto para a próxima vez que enfrentar essa escolha:
- O evento é semântico (algo aconteceu) ou técnico (um registro mudou)? Semântico → Platform Events. Técnico → CDC.
- Você controla o consumer? Se é SOAP-only externo e confiabilidade > latência → Outbound Messaging. Caso contrário → Platform Events ou CDC via Pub/Sub API.
- Diff em nível de campo importa? Sim → CDC (você ganha de graça). Não → Platform Events (payload menor, schema custom).
- Ordenação é crítica por registro? CDC ordena por transação por registro. Platform Events não ordena nada. Outbound Messaging ordena por regra.
- O volume vai exceder 50k eventos/hora sustentado? Planeje a cota diária e Pub/Sub API. Outbound Messaging está fora desse ponto em diante.
O erro mais comum: cair em Platform Events por default porque é o mais flexível. Flexibilidade corta dos dois lados — significa que agora você é responsável pela lógica do publisher, pelo schema do evento, pela estratégia de ordenação e pelo tratamento de replay. CDC entrega a maior parte disso de graça se o caso de uso bate. Use o mecanismo mais simples quando o contrato dele combina.
Isso encerra a série Salesforce Orientado a Eventos. A Parte 1 cobriu as arestas operacionais de Platform Events; esta parte deu o framework para escolher entre os quatro mecanismos.
Dúvidas ou histórias de guerra? Me encontre no LinkedIn.
