Integração é onde a maioria dos projetos Salesforce quebra. Não na fase de descoberta, não no UAT — quebra em produção, seis meses depois, quando o volume triplicou e ninguém lembra mais por que aquela chamada HTTP está ali sem retry.
Este é o primeiro post de uma série de três. Começo pelos padrões porque escolher errado aqui é caro: refatorar uma integração síncrona para assíncrona depois que ela está em produção é um tipo especial de dor.
Os quatro padrões principais
Toda integração Salesforce se encaixa em um destes quatro padrões — ou numa combinação deles.
Síncrono por requisição
O usuário clica, o Salesforce chama o sistema externo, espera a resposta, continua. Simples de entender, simples de debugar.
O problema: o sistema externo controla o tempo de resposta. Se ele leva 8 segundos numa chamada Apex, você está a dois segundos do timeout da transação de UI (10s). E timeout silencioso é pior do que erro explícito.
Use quando: a resposta é necessária imediatamente para continuar o fluxo (validação de CPF, consulta de estoque em tempo real).
Assíncrono por fila (Platform Events / Pub-Sub)
O Salesforce publica um evento, o consumidor processa quando pode. O produtor não espera.
É o padrão que eu mais recomendo para integrações de escrita. Volume alto, falha isolada, retry natural. A desvantagem é que você perde a resposta imediata — se o sistema externo rejeitar o registro, você vai saber depois.
Use quando: o volume é alto, a latência não precisa ser zero, e você pode lidar com falha assíncrona.
Batch agendado
ETL clássico. Um job Apex ou um Data Loader roda em horário fixo e sincroniza dados em lote. Previsível, barato, fácil de monitorar.
O problema real: a janela de dados desatualizados. Se o batch roda a cada hora, você tem até 59 minutos de divergência entre sistemas. Para a maioria dos dados de referência isso é aceitável. Para estoque ou precificação dinâmica, não.
Use quando: os dados não precisam estar sincronizados em tempo real e o volume inviabiliza chamadas individuais.
Change Data Capture (CDC)
O Salesforce emite um evento toda vez que um registro é criado, atualizado ou deletado. O consumidor externo assina o canal e reage à mudança.
Extremamente poderoso para manter sistemas externos em sincronia sem polling. A limitação é que CDC só funciona nos dois sentidos se o sistema externo também suportar streaming — caso contrário você ainda precisa de uma rota de escrita separada.
Use quando: você precisa que um sistema externo reaja a mudanças no Salesforce em near-real-time.
A decisão que mais influencia o padrão
Uma pergunta resolve 80% das dúvidas de padrão:
Quem precisa da resposta, e quando?
Se é o usuário, agora, na mesma tela: síncrono.
Se é um processo downstream, não importa quando: assíncrono ou batch.
Se é um sistema externo que precisa espelhar o Salesforce: CDC.
Trade-offs que a documentação omite
| Padrão | Ponto cego comum |
|---|---|
| Síncrono | Sem circuit breaker nativo — uma API instável derruba a UX |
| Platform Events | Ordem de entrega não garantida por padrão |
| Batch | Falha de um job não relança automaticamente |
| CDC | Replay window de 72h — depois disso, o evento sumiu |
O que o padrão não resolve
Escolher o padrão certo é necessário, mas não suficiente. Há problemas que nenhum dos quatro padrões resolve por si só.
Consistência eventual é um estado de negócio, não só técnico. Se você escolhe assíncrono, os times de produto e negócio precisam aceitar que há uma janela onde os sistemas estão dessincronizados. Isso parece óbvio no papel e vira surpresa em produção quando o usuário vê dados diferentes em sistemas diferentes.
Nenhum padrão substitui um contrato de API bem definido. Platform Events, CDC ou chamadas síncronas — se o sistema externo muda o schema sem aviso, qualquer implementação quebra. O padrão determina como a integração falha; o contrato determina se ela falha.
Autenticação e autorização ficam fora do padrão. OAuth, certificados, Named Credentials — esse é um layer separado que precisa ser projetado independente de qual padrão você escolher.
Reprocessamento histórico não é gratuito. Com batch você pode re-rodar. Com CDC, depois de 72 horas a janela de replay fecha. Com Platform Events, o mesmo. Se você precisa reprocessar dados de uma semana atrás depois de um bug, a resposta depende do padrão — e às vezes não tem resposta boa.
Conclusão prática
- Se a resposta é necessária para o usuário completar uma ação → síncrono, mas projete o timeout explicitamente
- Se o volume é alto ou a latência pode ser gerenciada → Platform Events; invista no tratamento de falha desde o início
- Se os dados são de referência e mudança lenta → batch agendado é suficiente e mais fácil de operar
- Se você precisa manter um sistema externo em sincronia com o Salesforce → CDC, mas verifique se o consumidor suporta streaming antes de comprometer a arquitetura
No próximo post entro na implementação: como estruturar o código Apex para cada um desses padrões sem transformar a org numa bomba relógio.
Qual padrão você mais usa? Me conta no LinkedIn.
