La elección que no se trata realmente de tecnología
Cuando una organización comienza a hablar de una Arquitectura Event Driven (EDA) en Salesforce, la conversación se inclina demasiado rápido hacia "¿Platform Events o CDC?" — como si fuera una cuestión de herramientas. En realidad, se trata de una pregunta completamente diferente: ¿qué lado de la integración es la fuente de la verdad, qué puede permitirse perder, y quién asume el costo cuando un mensaje llega tarde, duplicado o no llega en absoluto?
La respuesta corta: Change Data Capture (CDC) es adecuado cuando un sistema externo necesita saber que Salesforce ha actualizado un registro y no hay necesidad de envolverlo con lógica de negocio. Los Platform Events personalizados son adecuados cuando se desea publicar un evento de negocio significativo — "el cliente actualizó su plan", no "el campo _Status_c cambió". La elección incorrecta no se hace evidente el día del lanzamiento; se hace evidente cuando alguien necesita reconstruir lo sucedido después de un fallo parcial y descubre que no hay una forma fiable de saberlo.
Quien busque una visión más amplia de las integraciones de Salesforce más allá de los eventos la encontrará en la guía de arquitectura CRM.
Tres preguntas que definen la arquitectura antes de escribir una línea de código
Antes de elegir un mecanismo, se necesita una respuesta a tres preguntas. Omitir una de ellas es la razón más común por la que los proyectos de integración se estancan en la fase de pruebas.
¿Quién es el dueño del dato? Si Salesforce es la fuente de la verdad para el registro del cliente, los eventos de salida de Salesforce (Platform Event o CDC) son la dirección natural. Si el sistema ERP es el propietario, la dirección opuesta es correcta, y Salesforce debe consumir eventos en lugar de publicarlos sobre la misma entidad.
¿Qué se puede perder? Una alerta a un dashboard de gestión puede perder un solo mensaje sin causar daño. Una actualización del saldo de crédito antes de aprobar una transacción no puede. Esta distinción determina si es suficiente un "disparar y olvidar" (Fire-and-Forget) o si se requiere un mecanismo de confirmación y monitoreo de discrepancias (Reconciliation).
¿Qué sucede cuando el mensaje llega dos veces? Los Platform Events garantizan At-Least-Once, no Exactly-Once. Si la respuesta es "no sabemos" — la solución aún no está lista para producción, independientemente de la limpieza del código.
Platform Events vs. CDC — Tabla de decisión
| Criterio | Platform Event personalizado | Change Data Capture (CDC) |
|---|---|---|
| Qué se publica | Evento de negocio definido (Payload personalizado) | Cambio de registro en bruto (Antes/Después) |
| Quién construye la lógica | Desarrollador de Salesforce, en el Trigger o Flow | La plataforma, automáticamente para cada DML configurado |
| Acoplamiento al esquema | Bajo — el Payload es controlado por el publicador | Alto — cualquier cambio en la estructura del objeto afecta al consumidor |
| Adecuado cuando... | Se desea publicar una intención de negocio ("orden aprobada") | Se desea una sincronización de datos en bruto entre sistemas |
| Costo de mantenimiento | Más alto al principio (construcción del Payload y la lógica) | Bajo al principio, alto cuando cambia la estructura del objeto |
| Retención | Según la definición de la licencia (horas a días) | Según la definición de la licencia, generalmente igual que los Platform Events |
| Volumen recomendado | Eventos de dominio con frecuencia media | Cambios a nivel de registro, incluyendo alta frecuencia |
La regla práctica: si el consumidor del evento necesita entender "por qué" sucedió y no solo "qué" sucedió — se necesita un Platform Event personalizado. Si el consumidor solo necesita una copia actualizada del dato — CDC ahorra toda una capa de desarrollo.
Ordering, Replay e Idempotency: los tres conceptos que convierten la teoría en producción estable
Estos no son temas para una etapa tardía del proyecto — definen la estructura del consumidor desde el primer día.
Ordering. Los Platform Events se envían en el orden de publicación dentro del mismo tema, pero la carga y los fallos parciales pueden alterar el orden de recepción por parte del consumidor. Solución práctica: adjuntar a cada evento una marca de versión o Sequence Number del registro original, y permitir que el consumidor rechace un evento cuya versión sea inferior a la última versión ya procesada.
Replay. Cada evento recibe un Replay ID. Un consumidor que falla debe guardar el último Replay ID procesado con éxito — no en la memoria, sino en un lugar persistente (Custom Object, tabla externa) — y continuar desde allí con la recuperación. Confiar en que "el sistema comenzará desde cero" solo funciona dentro de la ventana de retención, y más allá de ella los eventos se pierden.
Idempotency. Cada consumidor debe identificar un evento que ya ha sido procesado, generalmente por un identificador de transacción único enviado dentro del Payload. Sin esto, un reintento automático por parte del remitente — o un Replay manual después de un fallo — se convierte en una actualización doble, la creación de un registro doble o, en el peor de los casos, un cargo doble.
Esta brecha casi nunca se detecta en la demostración. Se detecta bajo carga, en un fallo de red real o en un cambio en el entorno de producción, y entonces el costo de solucionarlo ya incluye también la corrección de datos. Las organizaciones que encuentran un problema paralelo en la capa de automatización encuentran un análisis complementario en deuda técnica de Salesforce en Flow y Apex.
Escenario de ejemplo: cadena minorista con 40 sucursales y sistema de inventario separado
Asumamos una cadena minorista hipotética, "Retail del Norte", que opera Salesforce Sales Cloud con equipos de ventas en 40 sucursales, y un sistema ERP separado que gestiona el inventario en tiempo real. Hasta ahora, cada pedido cerrado en Salesforce se transfería al ERP mediante un Job programado que se ejecutaba cada 15 minutos — una solución que provocaba que los representantes a veces vieran inventario desactualizado y aprobaran pedidos de productos agotados.
El equipo de arquitectura decidió publicar un Platform Event personalizado llamado Order_Confirmed__e cada vez que se aprobara un pedido, con un Payload que incluyera un identificador de transacción único, una lista de artículos y cantidades. El ERP escucha el evento y actualiza el inventario en segundos, verificando el identificador de transacción contra una tabla de transacciones ya procesadas — para evitar una doble deducción si el evento llegara dos veces.
Además, se definió un proceso de Reconciliation nocturno que compara el total de pedidos aprobados en Salesforce con el total de actualizaciones registradas en el ERP, y alerta sobre una discrepancia por encima de un umbral definido. La razón: incluso con una Idempotency correcta, se desea una detección temprana de un fallo de red prolongado y no solo confiar en que el evento "seguramente llegó". El resultado: el tiempo de actualización se redujo de 15 minutos a menos de un minuto, y el número de incidentes de inventario incorrecto disminuyó de manera medible en un mes desde la implementación.
Este escenario ilustra un principio clave: el valor no se crea por la "transición a eventos" en sí misma, sino por la combinación de un evento de negocio claro, una verificación de duplicados por parte del consumidor y un proceso de monitoreo que identifica una discrepancia antes de que se convierta en una queja de cliente.
Riesgos comunes y acciones de prevención
| Riesgo | Cómo se manifiesta en la práctica | Acción de prevención |
|---|---|---|
| Publicación de un evento por cada cambio de campo | La cuota diaria de eventos se excede en pocos días | Publicar eventos de dominio con significado de negocio, no un evento técnico por cada DML |
| No hay verificación de duplicados por parte del consumidor | Un reintento (Retry) o Replay crea registros o actualizaciones duplicados | Adjuntar un identificador de transacción único y verificarlo antes de cada operación |
| Confianza en el orden de llegada | Una actualización antigua sobrescribe una actualización más reciente | Adjuntar una marca de versión y rechazar eventos más antiguos que la última versión procesada |
| No se guarda el Replay ID | Después de una caída del consumidor, los eventos entre la caída y la ventana de retención se pierden | Guardar el Replay ID en un lugar persistente y ejecutar un Replay automático al reiniciar |
| CDC en un objeto cuya estructura cambia con frecuencia | Cada cambio de campo rompe el consumidor externo sin previo aviso | Definir un contrato de datos explícito y comunicar los cambios de esquema con antelación |
| No hay monitoreo de negocio, solo monitoreo técnico | La integración está "en verde" pero el inventario o los pedidos reales no coinciden | Añadir una Reconciliation diaria que compare el resultado de negocio entre los sistemas |
Checklist antes de empezar a desarrollar la capa de eventos
- ☐ Cada evento tiene un propietario claro: quién publica y quién es el propietario comercial del dato.
- ☐ Se ha definido un Payload consistente y documentado, no una estructura que cambia con cada Sprint.
- ☐ Se ha elegido entre Platform Event personalizado y CDC según la intención comercial frente al cambio de datos en bruto.
- ☐ Cada consumidor tiene un identificador de transacción único y verificación de duplicados (Idempotency).
- ☐ Se define el tratamiento del orden mediante una marca de versión, no por orden de llegada.
- ☐ El Replay ID se guarda en un lugar persistente y se define y prueba un proceso de recuperación.
- ☐ Existe un monitoreo comercial (Reconciliation) además del monitoreo técnico de la cola de mensajes.
- ☐ Se ha probado el escenario de carga y el escenario de fallo parcial, no solo el Happy Path.
- ☐ La cuota diaria de eventos (Publish + Delivery) se ha verificado frente al volumen esperado en producción.
- ☐ Se ha definido un Owner operativo para responder cuando se detecta una discrepancia en la Reconciliation.
¿Cómo se mide el funcionamiento de la arquitectura?
| Área | Qué se mide | Frecuencia de verificación |
|---|---|---|
| Fiabilidad de la entrega | Porcentaje de eventos completados sin reintento (Retry), y porcentaje que tuvo éxito después del reintento | Continuo |
| Discrepancias en Reconciliation | Diferencia entre los registros confirmados en el origen y los registros recibidos en el destino | Diario |
| Latencia de extremo a extremo | Tiempo entre el evento de negocio y la actualización efectiva en el consumidor | Continuo |
| Utilización de la cuota de eventos | Porcentaje de la cuota diaria utilizada | Semanal |
| Duplicados evitados | Número de eventos identificados como duplicados y bloqueados antes de su ejecución | Semanal |
Se recomienda elegir no más de tres o cuatro métricas para la primera versión, y medirlas contra una línea de base (Baseline) recopilada antes de la transición a la arquitectura de eventos — no contra una sensación general de que "ahora es más rápido".
Para una planificación más amplia de la estructura organizacional de múltiples integraciones, también es aconsejable revisar los patrones de integración de Salesforce y las implicaciones para la arquitectura Single Org vs. Multi Org de Salesforce, ya que una decisión sobre eventos a veces cruza los límites organizacionales.
Resumen
La elección entre Platform Events y CDC no es una cuestión técnica que se analiza en un corto período al inicio de un proyecto — determina quién es la fuente de la verdad, qué se puede perder y cómo se comporta el sistema cuando algo falla a mitad de camino. Una organización que planifica de antemano el Ordering, Replay e Idempotency, y añade una capa de Reconciliation de negocio y no solo un monitoreo técnico, obtiene una integración que soporta la carga y los fallos parciales. Una organización que omite estos pasos obtiene un sistema que parece correcto en las pruebas y que falla en silencio en producción, generalmente sin que nadie se dé cuenta hasta que el daño ya ha ocurrido.
Las organizaciones que desean acompañamiento en la construcción de una capa de eventos fiable en Salesforce pueden contactar a través del servicio de arquitectura CRM.