Replicación lógica vs ETL por lotes: elegir un estilo de sincronización

¿Qué problema resolvemos cuando “sincronizamos datos”?

Los equipos copian datos entre sistemas porque el trabajo rara vez ocurre en un solo sitio. Ventas puede vivir en un CRM, los pagos en una herramienta de facturación y operaciones en un panel interno. Soporte necesita la foto completa sin saltar entre herramientas, y los líderes quieren reportes que coincidan con lo que realmente pasó.

Una “sincronización confiable” es fácil de describir y difícil de mantener: los registros correctos llegan, nada importante falta y las actualizaciones aparecen lo suficientemente rápido como para ser útiles. “Lo suficientemente rápido” depende del trabajo. Las comprobaciones antifraude pueden necesitar minutos. Los reportes financieros mensuales pueden tolerar horas.

Cuando una sincronización falla, suele verse como registros faltantes, duplicados, campos obsoletos o actualizaciones parciales (por ejemplo, aparece el encabezado de un pedido pero no las líneas).

Un modelo mental útil es eventos vs instantáneas.

Los eventos son cambios individuales: “Pedido #1842 fue creado”, “estado cambió a enviado”, “se emitió un reembolso”. Los enfoques de cambio de datos tienden a mover eventos y pueden soportar comportamiento casi en tiempo real.

Las instantáneas son copias programadas: “cada noche, copia los pedidos de ayer”. El ETL por lotes suele funcionar así. Puede ser más simple, pero los datos son menos frescos.

La mayoría de las discusiones sobre replicación lógica vs ETL por lotes en realidad tratan esta elección: ¿necesitas eventos continuos o son suficientes instantáneas periódicas para que la gente confíe en lo que ve?

Replicación lógica y ETL por lotes, explicado de forma simple

La replicación lógica significa que la base de datos origen envía una secuencia de cambios a medida que ocurren. En lugar de copiar tablas enteras, publica “fila añadida”, “fila actualizada” o “fila eliminada”. El destino aplica esos cambios en orden, por lo que se mantiene muy alineado con la fuente.

El ETL por lotes significa que tomas instantáneas según un cron. Un trabajo extrae datos (a menudo “todo desde la última ejecución”), los transforma si hace falta y los carga en el destino. Si la replicación se siente como actualizaciones en vivo, el ETL por lotes se siente como consultar cada hora (o cada noche) y ponerse al día.

Suelen ejecutarse en lugares distintos. La replicación está cerca del log de cambios de la base y corre de forma continua. El ETL por lotes es típicamente un trabajo programado que corre, se detiene y vuelve a correr.

De cualquier forma, aún tienes que responder las mismas preguntas de confianza:

• ¿Cómo se representan los borrados para que el destino no conserve filas “fantasma”?
• ¿Qué pasa si el mismo cambio llega dos veces (idempotencia)?
• ¿Cómo mantienes el orden correcto cuando muchas filas cambian rápido?
• ¿Cómo evitas perder cambios durante reinicios o redeploys?
• ¿Cómo detectas huecos, no solo que “el trabajo tuvo éxito”?

Ejemplo: se crea un pedido, luego su estado cambia de “pendiente” a “pagado” y luego se reembolsa. La replicación envía tres eventos de cambio. Una instantánea diaria puede capturar solo el estado final, a menos que diseñes el proceso por lotes para preservar estados intermedios.

Frescura y latencia: ¿qué tan cerca del tiempo real necesitas estar?

Antes de comparar replicación y ETL por lotes, define “lo bastante fresco” en términos de negocio. Empieza con un número: “soporte puede trabajar con datos de hasta 5 minutos” o “finanzas acepta los totales de ayer”.

La frescura es la edad de los datos cuando alguien los usa. La latencia es el retraso entre un cambio en la fuente y el mismo cambio apareciendo en el destino. Puedes tener baja latencia promedio y aun así acabar con datos “viejos” si la sincronización se queda frecuentemente atascada.

De dónde viene realmente la latencia

Incluso una sincronización simple suma varios retrasos: captura (cuando detectas cambios), tránsito (mover los datos), procesamiento (transformaciones y desduplicación) y aplicación (escritura e indexado en el destino).

Un goteo constante (replicación o micro-lotes frecuentes) produce una frescura más homogénea, pero estás operando la sincronización todo el día. Los lotes programados son más fáciles de razonar, pero crean picos: carga pesada a las 2:00 AM y luego datos obsoletos hasta la siguiente ejecución.

El casi tiempo real ayuda cuando la gente toma decisiones rápidas o los clientes ven el resultado. Un panel de soporte debería mostrar pedidos nuevos rápidamente para que un agente no prometa algo que está agotado. Por otro lado, si el uso principal es un reporte semanal o facturación mensual, empujar cada pequeño cambio instantáneamente añade complejidad sin mejorar los resultados.

Una forma práctica de decidir:

• ¿Quién usa los datos sincronizados y qué decisiones toman con ellos?
• ¿Qué se rompe si los datos tienen 15 minutos de antigüedad?
• ¿Qué cuesta operar continuamente (infraestructura y tiempo on-call)?
• ¿Cuándo está menos ocupado el destino?
• ¿A qué frescura te comprometes (y comunicas)?

Recuperación ante fallos: volver al estado correcto después de un problema

Las sincronizaciones raramente fallan de forma dramática. Fallan de maneras pequeñas y aburridas: un servidor se reinicia, un problema de red corta una conexión o un trabajo se cae a mitad de una carga. La meta no es “nunca fallar”. Es “recuperar hasta un estado correcto”.

Los modos comunes de fallo incluyen una caída de la fuente, una caída del destino, un crash del trabajo durante el procesamiento o datos malos que violan restricciones.

Con replicación lógica, la recuperación suele significar reproducir cambios desde una posición guardada (a menudo un offset del log). Si el destino está abajo, los cambios se acumulan hasta que vuelve y luego continúan en orden. Eso es limpio si además gestionas la ranura de replicación (o equivalente) para que no crezca indefinidamente durante una salida prolongada.

Con ETL por lotes, la recuperación suele significar volver a ejecutar una ventana de tiempo (por ejemplo, “recargar ayer” o “recargar las últimas 2 horas”). Eso es a menudo simple operativamente, pero tu lógica de carga debe ser segura para ejecutar dos veces.

El mayor rompedor de confianza son las escrituras parciales. Un crash después de escribir el 70% de un lote puede dejar duplicados o filas faltantes a menos que lo planees. Patrones que ayudan en ambos estilos:

• Haz las cargas idempotentes para que aplicar la misma entrada dos veces termine en el mismo estado.
• Prefiere upserts con key por una clave primaria estable.
• Avanza tu marcador de “último procesado” solo después de un commit exitoso.
• Guarda las filas rechazadas en algún sitio donde puedas inspeccionarlas y volver a reproducirlas.

Los backfills (rehacer historia) son donde duele más. El ETL por lotes suele ganar cuando necesitas reprocesar un mes de datos porque las reejecuciones ya forman parte del diseño. La replicación también puede backfillear, pero a menudo es un camino separado (snapshot primero y luego aplicar cambios), así que vale la pena probarlo antes de necesitarlo.

Ejemplo: si una sincronización de pedidos se cae después de escribir las líneas pero antes de escribir el encabezado, una carga basada en upserts con una transacción por pedido (o por lote) evita que quede un pedido medio sincronizado.

Evolución del esquema: ¿qué pasa cuando cambia el modelo de datos?

Los cambios de esquema son donde muchas sincronizaciones pierden confianza silenciosamente. Un pipeline puede seguir funcionando mientras el significado de los datos cambia por debajo. La replicación puede romperse a nivel de base de datos, mientras que el ETL suele romperse más tarde en las transformaciones y reportes.

Los cambios aditivos son los más fáciles: nuevas columnas, nuevas tablas, campos opcionales. Suelen funcionar si los consumidores los tratan como “extras” y los valores por defecto son sensatos. La trampa es asumir que todos los consumidores downstream notarán el nuevo campo o sabrán cómo rellenarlo retroactivamente.

Los cambios rompientes son riesgosos: renombrados, cambios de tipo, columnas eliminadas o cambiar lo que significa un valor. Estos pueden fallar rápidamente (error del trabajo) o fallar silenciosamente (los datos aterrizan pero están equivocados).

Cómo evolucionar de forma segura

Mantén compatibilidad el tiempo suficiente para migrar:

• Versiona esquemas o payloads (v1, v2) para que viejo y nuevo coexistan.
• Ejecuta un periodo de compatibilidad donde existan ambos campos.
• Backfillea antes de activar la lógica que dependa de la nueva forma.
• Elimina campos solo después de confirmar que nadie los lee.

Dónde fallan los mapeos

La mayoría de las roturas reales ocurren en el pegamento entre sistemas. Ejemplo: tu ETL une orders con customers por customer_id. Si se renombra a client_id, la unión puede convertirse en coincidencias nulas y aun así producir filas.

Vigila puntos frágiles: casteos de tipo, joins que asumen que las claves nunca cambian y reglas downstream como “status es uno de estos valores”.

Seguridad y propiedad: ¿quién puede sincronizar qué?

Las preguntas de seguridad lucen similares en ambos enfoques, pero los riesgos aparecen en distintos puntos. La replicación suele correr continuamente con amplio acceso de solo lectura a los cambios. El ETL por lotes corre según un cron, pero puede extraer rebanadas de datos mayores a la vez. En ambos casos, busca los permisos mínimos que permitan hacer el trabajo.

Usa una cuenta de servicio dedicada, no el login de una persona. Da acceso read-only exactamente a las tablas, columnas o vistas que necesita y limita desde dónde puede conectarse. Cuando sea posible, expón una “vista de sincronización” dedicada que ya filtre los datos que el destino nunca debe ver.

Los campos sensibles son donde los equipos se sorprenden. Aunque el destino necesite un registro, puede que no necesite todo en él. Decide pronto si omitir, enmascarar o tokenizar datos personales, información de pago o notas internas. Encripta datos en tránsito y guarda secretos en un almacén de secretos adecuado, no en configuraciones del pipeline.

La propiedad evita discusiones interminables más adelante:

• Elige una fuente de verdad para cada campo (no solo para cada tabla).
• Define si el destino puede escribir de vuelta.
• Decide cómo se manejan conflictos (último write gana, ignorar ediciones en el destino, revisión manual).
• Establece reglas de retención para los datos copiados en el destino.

La auditoría es la última pieza de confianza. Debes poder responder: quién accedió a los datos, qué cambió y cuándo aterrizó. Una práctica simple es llevar un id de ejecución de sincronización trazable y timestamps para seguir una actualización de extremo a extremo.

Qué monitorizar para que la sincronización siga siendo confiable

Una sincronización solo es útil si puedes confiar en ella cualquier martes. Independientemente del enfoque, la monitorización debe decirte cuánto estás retrasado, con qué frecuencia fallas y si los números siguen teniendo sentido.

Tres señales de salud diarias:

• Lag/latencia: cuánto está el destino atrasado respecto a la fuente
• Tasa de error: fallos, reintentos y registros enviados a una cola de filas muertas o “failed rows”
• Throughput: filas o eventos procesados por minuto, además de caídas repentinas a casi cero

Luego añade un pequeño conjunto de chequeos de calidad de datos que atrapen problemas silenciosos. Elige algunas tablas importantes (orders, invoices, tickets) y valídalas de forma repetible. Si ayer hubo 1.240 pedidos en la fuente, el destino no debería tener 1.180 a menos que sepas por qué.

Cheques que suelen cubrir mucho:

• Recuentos de filas por día (u hora para feeds críticos)
• Totales que deberían coincidir (suma de importes, número de pedidos pagados)
• Tasa de nulos en campos requeridos (email, estado, timestamps)
• Unicidad de claves (no duplicados de order_id)
• “Verdad de borrado”: registros cancelados o eliminados también desaparecen (o se marcan) en downstream

Los problemas de consistencia a menudo se esconden en las grietas: actualizaciones que llegan tarde, borrados faltantes o eventos aplicados fuera de orden. Rastrea el timestamp no procesado más antiguo y muestrea periódicamente registros para confirmar que la versión más reciente está presente.

Para alertas, mantenlo aburrido y accionable. Define umbrales (por ejemplo: lag > 15 minutos, tasa de error > 1%, throughput por debajo de la línea base durante 10 minutos) y conserva un runbook que responda: qué revisar primero, cómo reejecutar de forma segura y cómo confirmar que volviste a un estado correcto.

Paso a paso: cómo elegir el enfoque de sincronización adecuado

Sé claro sobre quién usará los datos. Un reporte financiero, un panel de soporte y una regla automatizada de precios consumen las mismas tablas de maneras diferentes. Si las decisiones son sensibles al tiempo, los datos tardíos no son solo molestos: pueden ser erróneos.

Un proceso de decisión simple:

1. Nombre a los consumidores y sus decisiones. Lista las pantallas, reportes y procesos que dependen de la sincronización y qué afectan.
2. Fija objetivos, no sensaciones. Acordad la frescura (segundos, minutos, horas), la corrección (qué errores son aceptables) y el coste (infraestructura, tiempo de ingeniería, carga operativa).
3. Elige el patrón más sencillo que cumpla los objetivos. Usa replicación cuando necesites casi tiempo real y captura de cambios predecible. Usa micro-lotes cuando “cada pocos minutos” sea suficiente. Usa lotes nocturnos para reporting y snapshots históricos. El híbrido es común.
4. Planifica la recuperación. Decide cuánto hacia atrás puedes reproducir, cómo ejecutarás un backfill y cómo las cargas permanecen idempotentes.
5. Define chequeos de confianza y propiedad. Elige las validaciones que prueben la salud (recuentos, totales, última actualización, chequeos puntuales) y nombra quién recibe la alerta y quién corrige los datos.

Ejemplo concreto: si soporte necesita el estado del pedido mientras habla con un cliente, los minutos importan, así que replicación o micro-lote encajan. Si finanzas necesita números diarios, el lote nocturno suele bastar.

Errores comunes que hacen que los datos sincronizados no sean fiables

La trampa más grande es asumir que datos “frescos” son automáticamente datos “correctos”. Un pipeline puede tener segundos de retraso y aun así estar equivocado porque cambió una unión, se añadió un filtro o se duplicó una fila. Sin validación, no lo notarás hasta que un panel se vea raro o un cliente se queje.

Los borrados son otro fallo común. Ambos enfoques necesitan un plan claro para qué significa “eliminado”. Si el Sistema A borra físicamente un registro pero el Sistema B solo inserta y actualiza, los reportes derivan con el tiempo. Los soft-deletes son igual de problemáticos si la sincronización no transporta la bandera de borrado y el timestamp.

Errores que se repiten:

• Tratar la frescura como objetivo principal y saltarse recuentos básicos, totales y chequeos puntuales
• Sincronizar inserts y updates, pero no borrados, merges o estados desactivados
• Mapeos de campos codificados que fallan silenciosamente cuando una columna se renombra, divide o cambia de tipo
• No tener un plan de backfill cuando hay que corregir datos históricos
• Alertar solo en fallos de trabajo, no en lag, datos faltantes o deriva lenta

Ejemplo: tu CRM marca a un cliente como “inactivo” en lugar de borrarlo. Tu ETL solo copia clientes donde status = active. Un mes después, los reportes de ingresos parecen bien, pero las métricas de retención están infladas porque los clientes inactivos nunca llegaron (o nunca se eliminaron). Todo parecía fresco, pero la corrección ya estaba fallando.

Lista de verificación rápida antes de declarar la sincronización “hecha”

Acordad “hecho” en números claros, propiedad explícita y recuperación probada. Una sincronización que parece bien el día uno puede desviarse cuando empiezan los cambios reales y las fallas reales.

• Promesa de frescura escrita. Define el retraso objetivo, cuándo se mide y qué ocurre si lo incumples.
• Fuente de verdad explícita. Para campos clave (status, precio, email del cliente) documenta qué sistema manda y si las actualizaciones son unidireccionales o bidireccionales.
• Recuperación probada end-to-end. Simula una falla y confirma que puedes reproducir o rerunear sin duplicados ni filas faltantes.
• Reglas de cambio de esquema. Decide quién aprueba cambios, cómo se despliegan y cómo manejas renombres, cambios de tipo y columnas borradas.
• Monitorización accionable. Rastrear lag, tasa de error y chequeos de datos básicos, con alertas que indiquen a la persona on-call qué hacer a continuación.

Chequeo de realidad: si delivery_instructions se añade a pedidos, tu proceso debería dejar claro si se sincroniza automáticamente, falla ruidosamente o se ignora de forma segura.

Un ejemplo realista: sincronizar pedidos entre dos sistemas

Imagina una compañía con pedidos almacenados en PostgreSQL. Dos equipos necesitan esos datos: Soporte necesita un dashboard en vivo para responder “¿dónde está mi pedido?” y Finanzas necesita números diarios estables para cierre e informes.

Usan un enfoque mixto en lugar de forzar una sola herramienta para todo.

Para Soporte, usan replicación lógica para que nuevos pedidos y actualizaciones de estado aparezcan rápido en una DB optimizada para lectura que alimenta el dashboard. Para Finanzas, ejecutan ETL por lotes una vez al día fuera del horario de negocio. Carga los pedidos finalizados en el warehouse de reporting, aplica reglas de negocio (impuestos, descuentos, reembolsos) y produce una instantánea diaria que no cambia bajo sus pies.

Entonces ocurre un cambio de esquema: el equipo de producto añade refund_reason. Soporte lo quiere inmediatamente. La replicación puede pasar la nueva columna rápido, mientras que el job por lotes puede tratarla como opcional al principio (por defecto “unknown”) hasta que la lógica de reporting esté lista.

Un día el destino de Soporte está caído 3 horas. Cuando vuelve, la replicación se pone al día desde la posición guardada. El paso clave no es solo “se reanudó”, sino “está correcto”: verifican los recuentos de pedidos para la ventana de la caída y revisan puntualmente algunos pedidos recientes end-to-end.

Cada mañana comprueban un conjunto corto de señales antes de confiar en los números: lag de replicación, recuentos fuente vs destino de pedidos en las últimas 24 horas, duplicados en tablas de finanzas, éxito del lote más filas cargadas por ejecución, y una muestra pequeña de pedidos de alto valor verificados en ambos sistemas.

Próximos pasos: hacer la sincronización visible y fácil de operar

Después de elegir un enfoque (o híbrido), el trabajo real es convertir la sincronización en algo en lo que la gente pueda confiar día a día. Elige un objetivo medible y trátalo como una métrica de producto. Para la mayoría de equipos, el primer objetivo es frescura (qué tan nuevos están los datos) o precisión (con qué frecuencia están equivocados).

Empieza pequeño: una tabla, un stream de eventos o un flujo que importe (como pedidos o tickets). Estabiliza ese camino y luego copia el patrón. Expandir antes de poder detectar y arreglar rápidamente crea un lío más grande, más rápido.

Una vista práctica de “estado de sincronización” para equipos no técnicos suele incluir lag actual vs objetivo, última sincronización exitosa, último intento fallido, volumen procesado hoy vs rango esperado y una nota corta sobre qué hacer cuando el estado está en rojo.

Si quieres construir pantallas internas como esta rápido, una plataforma no-code como AppMaster (appmaster.io) puede ayudarte a lanzar una vista de monitorización y ajustarla según cambien los requisitos, sin reescribir todo cuando el esquema o el flujo evolucione.