Imagina una tienda con diez millones de pedidos en su base de datos. El equipo de análisis necesita consultar las ventas del día, así que copia esos pedidos a un almacén analítico cada noche. Si hoy han cambiado diez mil, volver a transferir los diez millones para actualizar el informe resulta caro y lento. Change Data Capture (CDC) permite identificar los cambios y enviar solo lo necesario.

La idea es sencilla: después de crear una copia inicial, el pipeline observa qué registros se insertan, modifican o eliminan en el origen. Cada cambio se convierte en un evento que el destino puede aplicar. Así se actualiza la parte afectada de los datos sin reconstruir todo el conjunto en cada ejecución.

Del sistema transaccional al analítico

La tienda usa una base de datos OLTP para registrar pedidos y pagos. Está optimizada para muchas transacciones cortas: crear un pedido, cambiar su estado o cancelar una compra. El equipo de negocio usa un sistema OLAP —un data warehouse, por ejemplo— para agrupar ventas por día, producto y región. Son trabajos distintos y conviene que las consultas analíticas no compitan con las operaciones de la tienda.

Sin CDC, una solución simple sería exportar toda la tabla pedidos de forma periódica. Con CDC, el recorrido cambia:

1. Copia inicial: se cargan en OLAP los pedidos existentes. Esta fase sigue siendo necesaria si el destino empieza vacío.
2. Captura: el proceso CDC lee los cambios confirmados desde el registro de transacciones de la base de datos, cuando el motor y el conector lo permiten. Por ejemplo, PostgreSQL usa su WAL y MySQL su binlog.
3. Aplicación: el pipeline transforma los eventos y actualiza las tablas analíticas. Debe conservar la clave del pedido y tratar correctamente los borrados.

Supongamos que ya se copiaron los diez millones de pedidos. Durante una hora se crean 8.000, se actualizan 1.500 y se cancelan 500. El siguiente paso procesa 10.000 cambios, no otros diez millones de filas. Si el pedido P-42 pasa de «pendiente» a «pagado», el destino actualiza ese pedido; si se elimina un registro, recibe un evento de borrado en vez de esperar a descubrir su ausencia en un nuevo volcado.

¿Qué ventajas aporta?

• Menos datos transferidos: cuando cambia una pequeña parte de la tabla, no hay que mover el conjunto entero en cada ciclo.
• Menos trabajo repetido: se reducen las lecturas completas del origen y las recargas del destino, aunque la captura también consume recursos.
• Datos más recientes: los cambios pueden fluir de manera continua o en lotes frecuentes, según el diseño y la capacidad de los sistemas. CDC no garantiza latencia cero.
• Inserciones, modificaciones y borrados visibles: un cursor como updated_at suele detectar altas y cambios, pero necesita una solución adicional para los borrados físicos; el registro de transacciones puede incluirlos.
• Más destinos posibles: los mismos eventos pueden alimentar analítica, búsquedas o cachés, siempre que cada consumidor aplique su propia lógica.

Las piezas que hay que cuidar

CDC no significa «configurar y olvidar». La carga inicial y la lectura del registro deben coordinarse para no perder cambios que ocurran mientras se copia la tabla. El proceso también necesita guardar su posición en el log para reanudar tras una interrupción y asegurar que el origen conserve los registros el tiempo suficiente.

En el destino, conviene aplicar eventos por clave de forma idempotente: si se reintenta una entrega, el pedido no debe duplicarse. También hay que vigilar el retraso entre origen y destino, los cambios de esquema y el significado de un borrado para las tablas analíticas. Si se pierde la posición del log o este expira antes de consumirse, puede hacer falta una nueva carga o una reconciliación.

Herramientas habituales

Debezium proporciona conectores que capturan cambios de bases de datos y los publican como eventos. Airbyte ofrece sincronización CDC en conectores compatibles para mover datos entre origen y destino. AWS Database Migration Service (DMS) permite combinar una carga inicial con replicación continua, o capturar solo los cambios si el destino ya está cargado. La compatibilidad y la configuración concreta dependen de la base de datos y del destino elegidos.

CDC no elimina la primera copia ni sustituye el diseño del modelo analítico. Su valor está en lo que sucede después: convertir millones de recargas repetidas en una secuencia manejable de cambios, para que los análisis sigan el ritmo del negocio sin volver a empezar cada vez.