Qual a diferença prática entre Fire-and-Forget e Request-Reply em uma integração Salesforce?

Em Request-Reply, o solicitante aguarda uma resposta e recebe confirmação imediata de sucesso ou falha da operação – ideal quando um usuário está em frente à tela e precisa do resultado para prosseguir. Em Fire-and-Forget, o remetente continua imediatamente e a resposta, se houver, chega assincronamente – adequado para atualizações que não bloqueiam um processo humano. A escolha errada faz os usuários esperarem por um sistema que não foi projetado para esperar, ou perder falhas silenciosas.

Quando o CDC é preferível ao Batch periódico para sincronização de dados?

O CDC (Change Data Capture) é preferível quando o volume de alterações em relação ao volume total é pequeno e quando é necessário refletir uma mudança em minutos, não em horas – por exemplo, a atualização de status de um pedido que afeta o atendimento ao cliente. O Batch é preferível quando é conveniente processar um grande volume em uma janela de tempo fixa, quando a fonte não suporta um Event Stream, ou quando o próprio processamento requer um cálculo sobre um conjunto completo de registros, e não apenas uma única alteração.

Como lidar com a duplicação de mensagens em uma integração baseada em eventos?

Assuma que toda mensagem pode chegar mais de uma vez e projete o lado receptor como Idempotente: um identificador exclusivo para cada mensagem, verificação se já foi processada antes de executar a ação, e salvamento do resultado para que uma execução repetida não crie um registro duplicado ou atualize duas vezes. Contar com a premissa de 'a mensagem chegará uma vez' é a suposição que primeiro falha sob carga ou falha de rede.

Quem é responsável pela fonte da verdade quando o mesmo campo é atualizado tanto no Salesforce quanto em um sistema externo?

É preciso decidir antecipadamente qual sistema é o proprietário do campo, e documentar isso no contrato de integração, não apenas na memória da equipe. A atualização bidirecional sem um proprietário definido cria loops de sincronização e um resultado final dependente do tempo. Quando há uma necessidade real de edição de ambos os lados, é necessária uma regra explícita de Resolução de Conflitos – por exemplo, 'a última atualização vence' baseada no Timestamp – e não a suposição de que essa situação não acontecerá.

Como saber se um padrão de integração escolhido ainda é adequado depois que a carga aumenta dez vezes?

Verifique três coisas: se o tempo de processamento ainda atende ao SLA (Service Level Agreement) definido, se a taxa de falhas e retentativas aumentou além de um limite pré-estabelecido, e se os limites da API do Salesforce (como Governor Limits ou API Calls) estão se aproximando do teto. Um aumento em qualquer um desses indicadores é um sinal para considerar a transição de Batch para CDC, a adição de Queueing, ou a divisão em processos paralelos – antes que o sistema falhe em produção.

Real-Time, Batch ou Event-Driven: Guia de Escolha de Padrão

Três Perguntas Que Definem o Padrão, Não a Ferramenta

O erro comum na escolha de uma integração com o Salesforce é começar pela ferramenta: MuleSoft, Platform Events, Bulk API ou um Webhook simples. A ferramenta é um resultado, não um ponto de partida. Três perguntas definem o padrão correto:

Em quanto tempo o outro lado precisa saber? Segundos, minutos, horas ou um dia — a diferença entre Real-Time e Batch.
Quem é o proprietário dos dados a qualquer momento? Se a resposta não for clara, nenhum padrão técnico resolverá o problema.
O que acontece se o outro lado não estiver disponível? A resposta "esperamos novamente" não é uma resposta — é preciso ter um comportamento definido: Retry, fila ou falha explícita.

Quem responde a essas três perguntas antes de escolher uma tecnologia quase sempre chega à mesma conclusão que um arquiteto experiente — mas sem pagar por tentativa e erro em produção. Uma expansão sobre a conexão entre esta decisão e a arquitetura geral pode ser encontrada no Guia de Arquitetura de CRM.

Mapa de Padrões: Quando Cada Um se Encaixa

Padrão	Tempo de Resposta Típico	Exemplo de Uso Típico	Custo de Manutenção	Risco Principal
Request-Reply Síncrono	Milissegundos a Segundos	Verificação de crédito antes da aprovação de uma transação na tela	Médio	Timeout trava o usuário
Fire-and-Forget	Imediato no envio, sem esperar resultado	Envio de evento para criar uma Task em outro sistema	Baixo-Médio	Falha silenciosa sem monitoramento
Batch Periódico	Horas a Um Dia	Sincronização diária de catálogo de produtos de um ERP	Baixo	Discrepâncias de tempo entre os sistemas
CDC (Change Data Capture)	Segundos a Minutos	Atualização de status de pedido que afeta o suporte	Médio-Alto	Carga no Event Bus em caso de muitas mudanças
Event-Driven (Platform Events / Pub-Sub)	Segundos	Notificação de evento de negócio para vários consumidores em paralelo	Alto na implantação, Baixo na manutenção	Exige disciplina de Schema e Versioning

A tabela é um ponto de partida para discussão, não um veredito final. Um único sistema pode, e às vezes deve, usar vários padrões simultaneamente, dependendo do tipo de dado.

Por Que a Latência Não é Suficiente Para Decidir

O segundo erro comum: decidir apenas pela latência e ignorar a consistência. Um padrão rápido que atualiza apenas um lado e deixa o outro "quase sincronizado" cria um problema mais grave do que um padrão lento, mas consistente—porque os usuários aprendem a não confiar nos dados e, então, contornam o sistema.

A pergunta correta é dupla: quão rápida a resposta é necessária, e quão grave é uma situação em que os dois lados não estão sincronizados por um momento. Um processo de precificação apresentado ao cliente exige tanto velocidade quanto consistência total — nesse caso, é necessário um Request-Reply síncrono com um Timeout definido e tratamento explícito de falhas. Uma atualização de "número de visualizações em um artigo" pode conviver tranquilamente com um atraso de minutos — nesse caso, Fire-and-Forget ou CDC são suficientes.

Propriedade dos Dados: Uma Decisão Que Precede Qualquer Padrão

Antes de escolher como os dados transitam entre os sistemas, é preciso decidir onde eles são "verdadeiros". Um campo que é atualizado em dois sistemas sem um proprietário definido cria um loop de sincronização: A envia para B, B atualiza e envia de volta para A, A envia novamente. Isso não é um cenário extremo — é o resultado esperado da sincronização bidirecional sem uma regra de decisão.

Uma regra prática de trabalho: para cada campo compartilhado, define-se um único Owner. Se houver uma necessidade de negócio real para edição de ambos os lados (por exemplo, o atendimento ao cliente atualiza o endereço tanto no Salesforce quanto no ERP), adiciona-se uma regra explícita de Conflict Resolution — último Timestamp ganha, ou um campo define e o outro é apenas para exibição. A gestão de permissões para esses campos sensíveis é discutida no Guia de Modelo de Permissões no Salesforce.

Tratamento de Falhas: O Teste Que a Maioria dos Projetos Pula

Quase toda integração passa por um teste de Happy Path. Poucas passam por um teste sistemático dos três cenários de falha a seguir:

O segundo sistema não está disponível no momento do envio – A mensagem é salva em uma fila e enviada novamente, ou é perdida?
A mensagem chega duas vezes (problema comum em Retry automático e Event Bus) – O lado receptor cria um registro duplicado?
A mensagem chega em ordem errada – A atualização de status "cancelado" que chega antes de "aprovado" causa um resultado incorreto?

Um sistema que não é construído como Idempotente (identificador único para cada mensagem + verificação se já foi processada) falhará precisamente nos dois primeiros cenários, e geralmente sob carga — ou seja, exatamente quando o negócio mais depende dele. As limitações da API e a lida com Throttling neste contexto são detalhadas no Guia de Limites de API Salesforce.

Estrutura de Decisão: Da Questão de Negócio ao Padrão

Pergunta feita primeiro	Se a resposta for "sim"	Se a resposta for "não"
O usuário está esperando na tela pelo resultado da integração?	Request-Reply síncrono com Timeout definido	Continuamos para a próxima pergunta
É necessária uma atualização em poucos minutos de uma única mudança?	CDC ou Platform Event	Continuamos para a próxima pergunta
Vários consumidores diferentes precisam saber sobre o mesmo evento?	Event-Driven com Pub-Sub	Continuamos para a próxima pergunta
É conveniente processar um grande volume em uma janela de tempo fixa?	Batch periódico	Avaliar Fire-and-Forget com fila

Este é um ponto de partida para discussão em reunião de arquitetura, não uma fórmula exaustiva — sempre há casos de fronteira (por exemplo, volume enorme que exige CDC mas também Reconciliação Batch diária como rede de segurança).

Cenário Ilustrativo: Rede de Clínicas Particulares com Vinte Unidades

Suponhamos uma rede de clínicas que utiliza o Salesforce para gerenciar consultas de pacientes e um sistema de faturamento separado (Billing) que, nesta fase, não pode ser substituído. A demanda: quando um paciente conclui uma consulta, o sistema de faturamento deve ser atualizado imediatamente, e quando um faturamento é atualizado (por exemplo, pagamento recebido), o Salesforce precisa refletir essa mudança para que o agente de serviço não solicite um pagamento duplicado.

A escolha inicial da equipe foi um Batch noturno bidirecional — simples de implementar, mas criou uma lacuna de até 24 horas em que os agentes viam informações desatualizadas e causava reclamações. A solução escolhida na prática: o sentido único (conclusão de consulta do Salesforce para o faturamento) mudou para Fire-and-Forget com fila de mensagens e Retry automático, pois não é necessário que o usuário espere. O sentido inverso (confirmação de pagamento do faturamento para o Salesforce) mudou para CDC, pois se trata de uma mudança pontual que precisa chegar em minutos. O Batch noturno permaneceu apenas como um mecanismo de Reconciliação — uma comparação diária que detecta lacunas e alerta, não como o principal canal de atualização.

O resultado: o tempo de atualização diminuiu de horas para minutos, e o mecanismo de Reconciliação capturou dois casos de mensagens perdidas no primeiro mês — exatamente sua função.

Riscos e Ações Preventivas Específicas para Integração

Risco	Como se manifesta na prática	Ação preventiva
Falta de Idempotência	Registros duplicados após Retry ou falha de rede	Identificador único para mensagem + verificação de existência antes da criação
Fonte de verdade indefinida	Loop de sincronização ou atualização "vencedora" aleatória	Owner definido para cada campo + regra de Conflict Resolution
Point-to-Point sem camada de integração	Qualquer mudança de esquema em um sistema quebra outra conexão	Camada de Middleware/API com contrato de versionamento explícito
Monitoramento apenas técnico	A integração está "verde" mas os pedidos estão faltando na prática	Métrica de Reconciliação de negócio, não apenas Uptime técnico
Ignorar Governor Limits	A integração falha justamente sob carga máxima	Planejamento de Bulkification e Backoff antecipados, não como reação

Checklist para Seleção de Padrão de Integração

☐ Tempo de resposta necessário definido em números, não na palavra "rápido"
☐ Owner único definido para cada campo compartilhado entre os sistemas
☐ Verificado o que acontece quando o outro lado não está disponível — e documentado
☐ Verificado o que acontece quando uma mensagem chega duas vezes
☐ Verificado o que acontece quando as mensagens chegam fora de ordem
☐ Existe um mecanismo de Reconciliação mesmo que o padrão principal seja assíncrono
☐ Limites de API e Governor Limits verificados em relação ao volume esperado em carga máxima
☐ Métricas de sucesso de negócio definidas, e não apenas técnicas

Métricas para Validação Contínua da Integração

Após o lançamento, é recomendável acompanhar apenas três a quatro métricas: taxa de mensagens bem-sucedidas na primeira tentativa, tempo de ponta a ponta real versus o SLA definido, diferenças diárias de Reconciliação entre os sistemas e proximidade dos limites da API. Um aumento consistente em qualquer uma delas — e não apenas um desvio pontual — é o sinal para considerar a transição para outro padrão, antes que o sistema falhe em produção. Considerações sobre identidade e permissões de acesso entre sistemas são detalhadas no Guia de SSO e Identidade no Salesforce.

Resumo

A escolha correta do padrão de integração não começa com a pergunta "qual ferramenta", mas com três questões: quão rápida a resposta é necessária, quem é o proprietário dos dados e o que acontece quando algo falha. Real-Time é adequado quando o usuário espera por um resultado; CDC e Event-Driven são adequados para atualização rápida de uma única mudança ou para distribuição a vários consumidores; Batch é adequado para grandes volumes em uma janela de tempo fixa. Em qualquer padrão, Idempotência, propriedade de dados definida e um mecanismo de Reconciliação não são "bom ter" — são a condição para que a integração resista a uma carga real e não apenas a uma demonstração.

Fontes Profissionais

Salesforce Integration Patterns — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html
Salesforce Data Integration Decision Guide — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html
HPI Pro – Arquitetura de CRM — https://hpi.pro/crm-architecture
HPI Pro – Integrações e Dados — https://hpi.pro/integrations-data

Tempo Real, Batch ou Orientado a Eventos? Escolhendo um Padrão de Integração para Salesforce