CDC y replicación: arquitectura para datos casi en tiempo real — Debezium, log-based vs trigger-based

Capítulo 23 de la Guía práctica para diseñar y operar la arquitectura de datos de tu empresa. En el capítulo anterior construimos pipelines de ingesta resilientes con idempotencia, backpressure y políticas de retry. Ahora damos un salto de calidad: capturar los cambios de las bases de datos operacionales en el momento en que ocurren, sin esperar a la ventana batch nocturna. Bienvenido al mundo del Change Data Capture.

TL;DR: El Change Data Capture (CDC) es la técnica que detecta y propaga los cambios de una base de datos (inserciones, actualizaciones y borrados) a otros sistemas casi en tiempo real. La aproximación log-based —leer el registro de transacciones de la base de datos— es hoy el estándar de facto porque no impacta en el rendimiento del sistema origen, mientras que las variantes trigger-based y query-based quedan relegadas a casos residuales. Debezium, la plataforma open source (Apache 2.0) del ecosistema Kafka, es referencia del mercado open source, con su versión estable 3.5.2 publicada en junio de 2026.

El día que la ventana batch se quedó pequeña

Hay un momento en la vida de casi toda plataforma de datos en el que el proceso nocturno deja de ser suficiente. No suele anunciarse con una alarma: llega en forma de pregunta incómoda. El director de operaciones de una cadena de retail quiere saber por qué el stock que muestra la web difiere del stock real de tienda. El responsable de riesgos de una entidad financiera pregunta por qué el sistema antifraude tarda ocho horas en enterarse de que una tarjeta ha sido clonada. El equipo de urgencias de un hospital necesita que el cuadro de mando de camas refleje los ingresos de los últimos minutos, no los de ayer a medianoche.

Todas estas preguntas tienen la misma raíz técnica: los datos viajan del sistema transaccional a la plataforma analítica mediante cargas batch periódicas, normalmente extracciones completas o incrementales por consulta que se ejecutan cada noche. Es un patrón robusto, bien entendido y barato de operar... hasta que la latencia de horas se convierte en un problema de negocio. Y cada vez lo es en más sectores.

La respuesta arquitectónica a ese problema tiene nombre propio desde hace más de una década: Change Data Capture. Pero conviene no dejarse llevar por la moda. CDC no es un sustituto universal del batch, es una herramienta con un coste operativo real que hay que saber cuándo pagar. Este capítulo recorre las tres familias de CDC, disecciona Debezium como implementación open source de referencia, aclara la relación entre CDC y replicación (que no son lo mismo, aunque se confundan constantemente) y termina con los criterios de selección de software y el checklist operativo que un equipo de datos necesita antes de poner un conector en producción.

Qué es exactamente Change Data Capture (y qué no es)

Empecemos por la definición, porque el término se usa con demasiada alegría. El Change Data Capture es el conjunto de técnicas que permiten identificar, capturar y entregar los cambios producidos en los datos de un sistema origen —típicamente una base de datos relacional— a uno o varios sistemas destino, de forma continua y con una latencia que va de milisegundos a pocos minutos. La unidad de trabajo del CDC es el evento de cambio: un registro que describe qué fila cambió, cómo cambió (INSERT, UPDATE o DELETE), cuándo, y habitualmente con qué valores antes y después.

Esa última parte es importante. Un buen sistema CDC no entrega solo "la foto nueva" de la fila: entrega el antes y el después (el before image y el after image), más metadatos de la transacción. Esa riqueza es lo que permite construir en el destino cosas que con batch son costosísimas: historificación tipo SCD (Slowly Changing Dimensions), auditoría completa de cambios, detección de borrados —el eterno punto ciego de las extracciones incrementales por consulta— o reconstrucción del estado en cualquier instante del pasado.

Y ahora lo que CDC no es. No es un bus de eventos de negocio: un evento de cambio dice "la fila 4711 de la tabla pedidos cambió su estado a 'enviado'", no "el pedido del cliente Pérez ha salido del almacén". La semántica de negocio hay que construirla encima, y confundir ambos planos es el origen de más de un proyecto fallido de arquitectura orientada a eventos. Tampoco es, por sí solo, una solución de replicación de bases de datos con garantías transaccionales completas: sobre eso volveremos en la sección de replicación, porque el matiz tiene consecuencias de diseño serias.

Las tres familias: query-based, trigger-based y log-based

Todo mecanismo de CDC responde a una pregunta engañosamente simple: ¿cómo se entera el sistema de captura de que algo ha cambiado en la base de datos? Hay tres respuestas posibles, y cada una define una familia con sus propias virtudes, dependencias y puntos débiles.

Query-based: preguntar una y otra vez

La aproximación query-based (también llamada polling o CDC por consulta) es la más antigua y la más intuitiva: se lanza periódicamente una consulta contra las tablas origen filtrando por una columna de control, normalmente un timestamp de última modificación o un identificador autoincremental. Todo lo que tenga un valor mayor que el de la última ejecución se considera cambio y se extrae. Es el patrón que implementan por defecto muchas herramientas de integración clásicas y el que, seamos honestos, sigue funcionando en miles de empresas.

Sus limitaciones son estructurales, no de implementación. La primera: no detecta borrados, porque una fila eliminada simplemente deja de aparecer en el resultado de la consulta. La segunda: pierde estados intermedios; si una fila cambia tres veces entre dos ejecuciones del polling, solo se captura la última versión. La tercera: exige que el modelo de datos colabore, con columnas de auditoría fiables y bien indexadas, algo que en aplicaciones heredadas es más deseo que realidad. Y la cuarta: el polling agresivo carga el sistema origen justo donde más duele, en las tablas transaccionales calientes.

Trigger-based: que la base de datos avise

La segunda familia invierte la lógica: en lugar de preguntar, se instruye a la base de datos para que notifique cada cambio mediante triggers. Por cada tabla a capturar se crean disparadores de INSERT, UPDATE y DELETE que escriben el cambio en una tabla auxiliar (una shadow table o tabla de cola), de la que el proceso de integración lee después. Esta técnica sí captura borrados, sí conserva cada cambio individual y funciona en prácticamente cualquier motor relacional, por veterano que sea.

El precio se paga en el peor sitio posible: dentro de la transacción de negocio. Cada trigger añade trabajo síncrono a la operación original; en tablas con miles de escrituras por segundo, ese sobrecoste (que en la práctica suele situarse en un rango muy apreciable de la latencia de escritura) puede degradar el rendimiento de la aplicación. Además, los triggers son objetos de base de datos que alguien tiene que versionar, desplegar y mantener sincronizados con cada cambio de esquema, y las tablas sombra crecen y hay que purgarlas. Los equipos de DBAs suelen mirar esta opción con la misma simpatía con la que un cirujano mira una infección: a veces es lo que hay, pero nadie la elige pudiendo evitarla.

Log-based: leer el diario íntimo de la base de datos

La tercera familia es la que ha ganado la partida. Toda base de datos relacional seria mantiene, por pura necesidad de durabilidad y recuperación, un registro de transacciones donde apunta cada cambio antes de confirmarlo: el binlog de MySQL y MariaDB, el WAL (Write-Ahead Log) de PostgreSQL, el transaction log de SQL Server, los redo logs de Oracle. El CDC log-based se conecta a ese registro —mediante APIs de replicación lógica, lectores de log o utilidades como LogMiner en el caso de Oracle— y lo convierte en un flujo de eventos de cambio.

Las ventajas son contundentes. El impacto sobre el sistema origen es mínimo y asíncrono: no se toca la transacción de negocio, no se añaden triggers, no se lanzan consultas pesadas; se lee un fichero de log que la base de datos ya estaba escribiendo de todos modos. Se capturan todos los cambios, en orden de commit, incluidos los borrados y cada estado intermedio. Y se obtienen los metadatos transaccionales que permiten reconstruir la consistencia en destino.

Los inconvenientes existen, y conviene nombrarlos antes de que salten en producción. El formato del log es interno y propietario de cada motor, así que se necesita un conector específico por tecnología, con sus peculiaridades y su ritmo propio de compatibilidad de versiones. Hay que ajustar configuración en el origen (activar el binlog en formato row, configurar publications y replication slots en PostgreSQL, habilitar CDC o replicación en SQL Server, dar permisos a LogMiner en Oracle), lo que exige negociar con el equipo que administra esa base de datos. Y aparece un riesgo operativo nuevo: si el consumidor se detiene demasiado tiempo, la retención del log puede agotarse (o un replication slot olvidado puede llenar el disco del servidor origen, un clásico de PostgreSQL que ha protagonizado más de un incidente serio).

La tabla siguiente resume la comparativa que un arquitecto necesita tener en la cabeza cuando le pregunten "¿y esto cómo lo capturamos?":

La conclusión es simple: en 2026, si puedes hacer log-based, haces log-based. Las otras dos familias son planes B legítimos cuando el acceso al log es imposible (una base de datos gestionada por un tercero que no expone replicación lógica, un motor exótico sin conector) o cuando el volumen es tan bajo que montar la maquinaria completa no compensa. Pero elegir triggers o polling "porque es lo que conocemos" teniendo el log disponible es hipotecar el rendimiento del origen y la calidad del dato a cambio de comodidad a corto plazo.

Debezium: la plataforma que estandarizó el CDC open source

Hablar de CDC log-based en 2026 es, inevitablemente, hablar de Debezium. Nacido en el entorno de Red Hat y publicado bajo licencia Apache 2.0 —open source de verdad, sin letra pequeña de las que analizamos en el capítulo 21—, el proyecto se ha convertido en una implementación de referencia y en la base sobre la que muchos servicios comerciales construyen su propia oferta de CDC. Su versión estable más reciente es la 3.5.2.Final, publicada el 2 de junio de 2026, con la serie 3.6 ya en fase de candidata a release; el proyecto mantiene una cadencia de publicación trimestral que dice mucho de la salud de su comunidad.

La propuesta de Debezium es conceptualmente elegante: convertir la base de datos en un flujo de eventos. Cada conector se especializa en un motor —MySQL, MariaDB, PostgreSQL, SQL Server, Oracle, MongoDB, Db2, Cassandra, Informix y una lista creciente— y traduce su log de transacciones a un formato de evento común, de modo que el consumidor final procesa los cambios de un Oracle y de un PostgreSQL con la misma estructura. Ese formato homogéneo, con su before, su after, su operación y sus metadatos de origen, es probablemente la mayor aportación de Debezium al sector: un estándar de facto para representar cambios.

Anatomía de un despliegue

La arquitectura canónica monta los conectores de Debezium sobre Kafka Connect, el framework de integración de Apache Kafka. El conector lee el log del origen, genera un evento por cada cambio de fila y lo publica en un topic de Kafka (habitualmente uno por tabla). A partir de ahí, el ecosistema hace el resto: conectores sink que vuelcan los eventos al data warehouse, al lakehouse o a un índice de búsqueda; aplicaciones de streaming que procesan los cambios al vuelo; o simplemente consumidores que alimentan la capa Bronze de una arquitectura ELT con enfoque Medallion. Kafka aporta lo que un pipeline de CDC necesita desesperadamente: durabilidad, orden por partición, desacoplamiento y capacidad de reprocesar (el consumidor puede detenerse y retomar donde lo dejó, o rebobinar y reconstruir un destino desde cero).

Para quien no quiere o no puede operar Kafka, el proyecto ofrece Debezium Server, un runtime autónomo que envía los eventos directamente a destinos como Google Pub/Sub, Amazon Kinesis, Azure Event Hubs, Redis Streams o HTTP, y el embedded engine, una librería para incrustar la captura dentro de una aplicación Java. Son opciones legítimas para escenarios acotados, aunque conviene ser consciente de lo que se pierde: sin Kafka en medio no hay buffer duradero que absorba las caídas del destino, y la responsabilidad de no perder eventos se desplaza a la aplicación.

El snapshot inicial: el peaje de entrada

Hay un detalle que las demos de cinco minutos siempre esquivan: el log de transacciones tiene una retención finita, así que el CDC solo puede capturar el presente. Para tener en destino el estado completo de una tabla hace falta primero una foto inicial, el snapshot, y solo después empezar a aplicar cambios desde el punto exacto del log en que se tomó esa foto. Debezium orquesta este proceso con varios modos de snapshot y, desde hace varias versiones, con los incremental snapshots: la posibilidad de fotografiar tablas grandes por fragmentos, en paralelo con la captura de cambios en curso, sin bloquear el origen ni detener el flujo. Para tablas de cientos de millones de filas, esta característica marca la diferencia entre un proyecto viable y una ventana de mantenimiento imposible de negociar.

Semánticas de entrega: la letra pequeña que define tu diseño

La garantía por defecto de Debezium es at-least-once: ningún cambio se pierde, pero tras un fallo y una recuperación pueden entregarse eventos duplicados. No es un defecto, es un contrato, y el destino tiene que honrarlo siendo idempotente: aplicar dos veces el mismo evento debe dejar el mismo resultado que aplicarlo una. Quien haya leído el capítulo 22 reconocerá el patrón: claves de negocio estables, escrituras tipo MERGE/upsert por clave primaria, deduplicación por identificador de evento o posición en el log. El CDC no elimina la necesidad de pipelines idempotentes; al contrario la hace más necesaria.

Este punto merece un matiz, porque la pregunta surge en muchos comités de arquitectura: ¿y el exactly-once? La respuesta corta es que el ecosistema ha avanzado (Kafka ofrece semánticas transaccionales, y Debezium ha incorporado soporte de exactly-once semantics para escenarios concretos), pero la ingeniería sensata sigue diseñando los destinos como si los duplicados fueran posibles. Porque tarde o temprano lo son: una restauración de backup, un reprocesado manual, una migración de conector... El destino idempotente es el cinturón de seguridad que no depende de que todos los demás conduzcan bien.

Los ángulos ciegos: esquema y transacciones

Dos temas más completan la anatomía. El primero es la evolución de esquema: cuando alguien añade una columna en el origen, los eventos empiezan a llegar con una estructura nueva. Debezium captura los cambios de DDL y versiona los esquemas de los eventos (típicamente con un schema registry y formatos como Avro), pero la compatibilidad hacia atrás del destino es responsabilidad del equipo de datos: un ALTER TABLE inocente en el ERP puede romper el consumidor si nadie gobierna ese contrato. Los contratos de datos que veremos al hablar de calidad en el próximo capítulo nacen exactamente de esta herida.

El segundo es la consistencia transaccional. Los eventos de Debezium respetan el orden de commit por tabla, pero una transacción de negocio que toca cinco tablas se convierte en eventos repartidos en cinco topics, que el destino aplicará sin la atomicidad original. Para la mayoría de los casos analíticos esto es irrelevante; para reconstruir estados consistentes multi-tabla en tiempo real hay que trabajar con los metadatos de transacción que Debezium emite o asumir una consistencia eventual con ventanas de convergencia. Negarse a asumirla suele salir más caro que rediseñar el consumidor.

CDC y replicación: parientes cercanos, oficios distintos

El título de este capítulo une dos términos que el mercado mezcla sin pudor, así que separémoslos con precisión, porque eligen arquitecturas distintas.

La replicación de bases de datos es la copia continua de datos entre instancias del mismo motor (o compatibles) con el objetivo primario de alta disponibilidad, recuperación ante desastres o escalado de lecturas. Puede ser física —se replican los bloques o el log binario tal cual, produciendo una réplica byte a byte, como hacen Oracle Data Guard o la replicación en streaming de PostgreSQL— o lógica —se replican los cambios a nivel de fila, lo que permite heterogeneidad de versiones y filtrado selectivo—. La réplica física es un clon: idéntica, consistente, y generalmente utilizable solo como standby o para lecturas.

El CDC, en cambio, no persigue clonar: persigue liberar los cambios para que otros sistemas —de otro fabricante, con otro modelo, con otro propósito— los consuman. Técnicamente, el CDC log-based es un primo directo de la replicación lógica (de hecho, el conector PostgreSQL de Debezium se apoya en la infraestructura de replicación lógica del propio motor), pero su producto final es un flujo de eventos, no una base de datos gemela.

¿Por qué importa la distinción? Porque se combinan. Un patrón extendido en entornos empresariales con sistemas críticos es no capturar contra el primario, sino contra una réplica: la base de datos de producción replica físicamente hacia un standby (alta disponibilidad ante todo) y el CDC lee de esa réplica o de un entorno derivado, aislando por completo la carga de integración del sistema que sostiene la operación. Es un patrón habitual, por ejemplo, en el sector sanitario y en banca, donde el sistema transaccional es intocable por contrato y por sentido común; la contrapartida es una latencia adicional (la de la propia replicación) y algunas restricciones técnicas según el motor y el modo de standby, que conviene validar con el fabricante antes de comprometer SLAs de frescura. La lección de arquitectura es transversal: la topología de captura es una decisión de diseño, no un detalle de configuración, y debe decidirse mirando a la vez los requisitos de disponibilidad del origen y los de frescura del destino.

CDC en la práctica: cuatro sectores, cuatro historias

La teoría se entiende mejor con las cicatrices de otros. Cuatro escenarios sectoriales, contados como los cuentan los equipos que los han vivido.

Fintech: el fraude no espera al batch. Una entidad de pagos europea procesaba la detección de fraude sobre cargas horarias de su base transaccional. El rediseño con CDC log-based sobre los sistemas de autorización redujo la latencia de detección de una hora a menos de diez segundos: cada autorización, cada cambio de estado de tarjeta y cada modificación de datos de cliente fluye como evento hacia el motor de reglas y el modelo de scoring. El aprendizaje menos evidente no fue técnico sino organizativo: el equipo antifraude tuvo que rediseñar sus reglas para operar sobre eventos individuales con consistencia eventual en lugar de sobre fotos completas y cuadradas, y ese cambio de mentalidad costó más que el despliegue de los conectores.

E-commerce: el inventario como flujo. Un retailer omnicanal sufría el clásico desfase entre el stock del ERP y el que mostraba la web, con su cortejo de pedidos cancelados y clientes irritados. La solución pasó por capturar con CDC las tablas de inventario y pedidos del ERP y proyectarlas, vía Kafka, sobre una vista materializada de disponibilidad que consume la web. La trampa que descubrieron en el camino: las cargas masivas nocturnas del propio ERP (reaprovisionamientos, ajustes de inventario) generaban tormentas de cientos de miles de eventos en minutos, saturando a los consumidores. La respuesta fue puro capítulo 22: backpressure, procesamiento por lotes en el consumidor y, en algunos casos, compactación de topics para quedarse con el último estado por clave.

Sanidad: del HIS al cuadro de mando. Un operador hospitalario necesitaba alimentar en tiempo casi real su cuadro de mando de ocupación y urgencias sin tocar el rendimiento del sistema de información hospitalario, un requisito innegociable. El diseño optó por capturar no contra el HIS de producción sino contra su infraestructura de réplica, combinando la replicación física existente (pensada para contingencia) con captura de cambios aguas abajo hacia la plataforma analítica. Resultado: cuadros de mando con minutos de frescura, cero impacto medible en el transaccional y un aprendizaje clave sobre gobierno del dato: al fluir los cambios en segundos, los errores también llegan en segundos, y hubo que añadir validaciones en el pipeline para que un apunte erróneo corregido al instante en origen no disparara alertas espurias en el cuadro de mando.

Logística: la trazabilidad que vende. Un operador logístico convirtió el CDC en producto: capturando los cambios de estado de los envíos desde sus sistemas operacionales y exponiéndolos como eventos a sus clientes corporativos, transformó lo que era una consulta batch nocturna ("¿dónde está mi palet?") en notificaciones en tiempo casi real. El matiz de consultoría: el contrato con el cliente se definió sobre el evento de negocio ("envío entregado"), no sobre el evento de cambio en bruto ("UPDATE en la tabla shipment_status"), con una capa intermedia de transformación que traduce y estabiliza. Exponer eventos CDC crudos a terceros es acoplar tu esquema interno de base de datos a contratos externos: un error que se paga a la larga.

Riesgos frecuentes y anti-patrones: donde los proyectos de CDC se rompen

La experiencia acumulada del sector en proyectos de CDC dibuja un mapa de errores sorprendentemente repetitivo. Merece la pena recorrerlo con calma, porque casi todos son evitables en la fase de diseño.

El CDC como martillo universal. El anti-patrón número uno es adoptar CDC para flujos que no lo necesitan. Una tabla de referencia que cambia dos veces al año no necesita un conector, un topic y una cadena de consumo monitorizada 24x7: necesita una carga batch semanal. Cada conector CDC es infraestructura viva con coste de operación permanente; multiplicarlos sin criterio convierte la plataforma en un jardín de procesos frágiles que nadie recuerda por qué existen. La pregunta correcta nunca es "¿podemos capturar esto en tiempo real?" sino "¿qué decisión de negocio mejora si este dato llega en segundos en lugar de en horas?".

Ignorar la retención del log y los offsets. El incidente más clásico del CDC log-based: el conector se detiene un viernes (un despliegue, un fallo de red, una credencial caducada), nadie lo advierte, y el lunes el punto del log desde el que debía retomar ya no existe porque la retención era de 48 horas. Resultado: hay que re-snapshotear, con el coste y la ventana que eso implica. La variante PostgreSQL es aún más traicionera: el replication slot huérfano impide purgar el WAL y llena el disco del servidor de producción, convirtiendo un problema de integración en un incidente del sistema origen. La mitigación es conocida: monitorizar el lag de replicación y la edad de los slots como métricas de primer nivel, con alertas propias, y dimensionar la retención del log para no sufrir el fin de semana.

Subestimar el snapshot inicial. Planificar el streaming con mimo y despachar la carga inicial con un "eso es un full load de toda la vida" es otra receta clásica de sufrimiento. En tablas de gran volumen, el snapshot compite por recursos con la operación normal, puede requerir horas o días y debe encadenarse sin fisuras con el arranque del streaming. Los incremental snapshots de Debezium alivian el problema, pero no eximen de planificarlo: ventanas, throttling, orden de tablas, verificación de conteos al finalizar.

Olvidar los DELETE... otra vez. Parece un chiste después de años de sufrir el punto ciego del incremental por consulta, pero ocurre: el pipeline CDC captura los borrados y el destino no sabe qué hacer con ellos, porque el modelo del warehouse asumía solo inserciones y actualizaciones. Los tombstones y eventos de DELETE requieren una decisión explícita de modelado en destino: ¿borrado físico, borrado lógico con marca temporal, historificación completa? No decidirlo a tiempo significa descubrir en producción tablas que nunca menguan o métricas que cuentan clientes dados de baja.

Acoplar consumidores al esquema físico del origen. Cuando quince consumidores leen directamente los topics crudos de CDC, cada ALTER TABLE del sistema origen se convierte en un ejercicio de coordinación con quince equipos. La práctica sana interpone una capa: topics crudos como detalle de implementación interna del equipo de plataforma, y vistas o topics derivados con contrato estable hacia el resto de la organización. Es más trabajo el primer mes y muchísimo menos cada mes siguiente.

Confiar la seguridad al azar. Un flujo CDC transporta, potencialmente, cada dato personal que cambia en la base de datos origen, incluidas columnas que el destino analítico jamás debería ver. El filtrado y enmascaramiento de columnas en el conector (Debezium lo soporta de serie), el cifrado en tránsito y el gobierno de quién puede consumir qué topic no son un añadido de la fase dos: en cuanto hay datos personales en juego, el RGPD aplica al flujo igual que al reposo, y el flujo es más difícil de auditar a posteriori.

Cómo elegir software de CDC: criterios y mapa de mercado

Llegamos a la pregunta con la que suele empezar (erróneamente) más de un proyecto: ¿qué herramienta compramos? Como en toda la Parte III de esta guía, la respuesta empieza por los criterios, no por los logos.

El primer criterio es la cobertura de conectores para tus orígenes concretos, en tus versiones concretas. No "soporta Oracle": soporta tu Oracle 19c en RAC con las opciones de licencia que tienes, capturando desde standby si tu topología lo exige. La matriz de compatibilidad real, validada con una prueba de concepto sobre tu entorno, vale más que cualquier presentación. El segundo es el modelo de captura: log-based nativo debería ser requisito eliminatorio salvo justificación documentada. El tercero, las garantías de entrega y la tolerancia a fallos: qué pasa exactamente cuando el conector cae, cuándo se re-snapshotea, cómo se gestionan los offsets, qué semántica se ofrece de extremo a extremo.

Siguen los criterios operativos, que son los que determinan el coste real a tres años: observabilidad (métricas de lag, throughput y errores exportables a tu plataforma de monitorización), gestión de la evolución de esquema, integración con tu catálogo y lineage (los eventos CDC son un origen de lineage valiosísimo si tu catálogo sabe leerlos), y el modelo de despliegue: autogestionado sobre tu Kafka, servicio gestionado en cloud, o appliance comercial. Y, por supuesto, el modelo de licencia y coste, con la distinción que ya establecimos entre open source real (Apache 2.0, MIT), source-available y comercial, y con atención a cómo escala el precio: por conector, por volumen de datos, por núcleos del origen... Los modelos de precio por volumen pueden convertir un éxito de adopción en un problema presupuestario.

Con esos criterios, el mapa de mercado de 2026 se ordena en tres grandes grupos. En el polo open source, Debezium es la referencia indiscutible, con la contrapartida de que operarlo exige operar bien Kafka y Kafka Connect. En el polo comercial de replicación empresarial veterana están Oracle GoldenGate (el peso pesado histórico, especialmente fuerte en entornos Oracle-céntricos y escenarios de migración con mínima parada) y Qlik Replicate, junto a plataformas de streaming como Striim. En el terreno de los servicios gestionados, AWS DMS ofrece CDC como servicio dentro del ecosistema Amazon, y las plataformas de integración como Fivetran (que incorpora la tecnología de HVR para CDC empresarial y que, tras completar su fusión con dbt Labs el 1 de junio de 2026, forma parte de un actor de integración de primer orden) o Airbyte en el mundo open core, empaquetan CDC —a menudo con Debezium bajo el capó— como parte de una oferta ELT más amplia. En nuestra valoración, la decisión rara vez es puramente técnica: es la intersección entre tu stack de orígenes, tu capacidad de operación y tu modelo de sourcing. Un equipo pequeño sin experiencia en Kafka probablemente esté mejor servido por un servicio gestionado aunque el precio unitario duela; una plataforma de datos con equipo propio y volúmenes serios amortiza Debezium en meses.

Checklist operativo: antes de poner un conector CDC en producción

Como en cada capítulo, cerramos la parte técnica con la lista que conviene repasar —y documentar— antes del paso a producción:

• Justificación de negocio documentada: qué decisión o proceso mejora con latencia de segundos, y qué flujos permanecen en batch deliberadamente.
• Topología de captura decidida: primario o réplica, con validación del impacto en el origen firmada por el equipo que lo administra.
• Configuración del origen verificada: formato de log adecuado (binlog en modo row, WAL con nivel logical, CDC habilitado en SQL Server, permisos de LogMiner en Oracle) y retención dimensionada para sobrevivir al peor escenario de parada del consumidor.
• Plan de snapshot inicial: ventana, modo (bloqueante o incremental), orden de tablas, verificación de conteos y encadenado con el streaming.
• Destino idempotente: upsert por clave, deduplicación por posición de log o identificador de evento, y tratamiento explícito de los DELETE (físico, lógico o historificación).
• Gestión de esquema: schema registry o equivalente, política de compatibilidad definida y procedimiento pactado para cambios de DDL en origen.
• Observabilidad de primer nivel: lag de replicación, edad de slots/offsets, throughput y errores con alertas propias, integrados en la monitorización general de la plataforma.
• Runbook de incidentes: qué hacer ante pérdida de posición en el log, cómo re-snapshotear una tabla sin parar el resto, cómo pausar y reanudar conectores.
• Seguridad y cumplimiento: filtrado y enmascaramiento de columnas sensibles en el conector, cifrado en tránsito y autorización de acceso a los topics documentada.
• Contratos hacia consumidores: capa derivada estable entre los topics crudos y el resto de la organización, con propietario asignado.

Formación recomendada

Para llevar estos conceptos al terreno práctico, estos cursos están directamente relacionados con el contenido del capítulo (los tres en inglés):

• Introduction to Apache Kafka (DataCamp): los fundamentos de Kafka —topics, producers, consumers, brokers— que constituyen la columna vertebral de cualquier despliegue de Debezium, en el formato interactivo de DataCamp (2 horas).

• Apache Kafka Series – Kafka Connect Hands-on Learning (Udemy): el framework sobre el que se despliegan los conectores de Debezium, con práctica de conectores source y sink en modo standalone y distribuido.

• Change Data Capture (CDC) using Debezium for MySQL (Udemy): monográfico práctico de Debezium con MySQL, desde la arquitectura del conector y el binlog hasta el despliegue en modo distribuido y los incremental snapshots mediante señales.

Preguntas frecuentes sobre CDC y replicación

¿Qué es Change Data Capture (CDC)?

Es el conjunto de técnicas que identifican y capturan los cambios (inserciones, actualizaciones y borrados) producidos en una base de datos y los entregan a otros sistemas de forma continua, con latencias de milisegundos a minutos, en forma de eventos de cambio que describen el antes y el después de cada fila.

¿Cuál es la diferencia entre CDC log-based y trigger-based?

El CDC log-based lee el registro de transacciones que la base de datos ya mantiene (binlog, WAL, redo logs), de forma asíncrona y con impacto mínimo en el origen. El trigger-based intercepta cada cambio con disparadores que escriben en tablas auxiliares, añadiendo trabajo síncrono a cada transacción de negocio. El log-based es el estándar recomendado; el trigger-based queda para motores sin acceso al log y volúmenes bajos.

¿Qué es Debezium y cuánto cuesta?

Debezium es la plataforma open source de referencia para CDC log-based, publicada bajo licencia Apache 2.0 (gratuita, sin restricciones de uso comercial). Ofrece conectores para MySQL, PostgreSQL, SQL Server, Oracle, MongoDB, Db2 y otros motores, y se despliega habitualmente sobre Kafka Connect. El coste real es operativo: la infraestructura Kafka y el equipo que la opera. Su versión estable en junio de 2026 es la 3.5.2.

¿CDC sustituye a las cargas batch?

No. CDC resuelve los flujos donde la latencia de horas tiene coste de negocio; el batch sigue siendo la opción más simple y barata para datos de cambio lento, cargas históricas y fuentes sin requisitos de frescura. Las plataformas maduras combinan ambos deliberadamente.

¿Es lo mismo CDC que replicación de bases de datos?

No. La replicación copia datos entre instancias del mismo motor (o compatibles) buscando alta disponibilidad o escalado de lecturas; puede ser física (clon exacto) o lógica (a nivel de fila). El CDC libera los cambios como eventos para que sistemas heterogéneos los consuman. Comparten técnicas (ambos pueden leer el log de transacciones) y se combinan a menudo: capturar contra una réplica en lugar del primario es un patrón habitual en sistemas críticos.

¿Qué garantías de entrega ofrece un pipeline CDC?

La garantía habitual es at-least-once: ningún cambio se pierde, pero pueden entregarse duplicados tras un fallo. Por eso el destino debe ser idempotente (upserts por clave, deduplicación por posición de log). Existen configuraciones con semántica exactly-once para escenarios concretos, pero la práctica recomendada es diseñar los destinos asumiendo duplicados posibles.

En resumen

El Change Data Capture es la pieza que convierte una plataforma de datos de espejo retrasado en sistema nervioso: cada cambio del mundo operacional, disponible en segundos para análisis, operaciones y productos de datos. La técnica ganadora es el log-based, la herramienta open source de referencia es Debezium sobre Kafka, y las claves del éxito son las menos glamurosas: dimensionar la retención del log, planificar el snapshot, monitorizar el lag como métrica de primer nivel, mantener destinos idempotentes y gobernar los contratos de esquema. Y, sobre todo, la disciplina de aplicar CDC solo donde la frescura del dato paga su coste operativo.

En el próximo capítulo abordamos la consecuencia natural de mover datos a esta velocidad: si los datos fluyen en segundos, los errores también. Hablaremos de calidad de datos en el pipeline: validaciones, observabilidad y SLAs de calidad.

Contenido elaborado con asistencia de inteligencia artificial — Equipo Editorial Dataprix. Verifica la información antes de tomar decisiones.

Última actualización: julio de 2026.