Change data capture: mantén dos bases de datos sincronizadas

Change data capture (CDC) es una técnica que detecta cada insert, update y delete en una base de datos y transmite esos cambios a otro sistema. La segunda base de datos se mantiene sincronizada con la primera sin que nadie copie datos a mano ni ejecute exportaciones nocturnas.

En una migración con el sistema en vivo, el CDC permite que la base de datos antigua y la nueva funcionen en paralelo mientras los usuarios siguen trabajando. Esta guía explica cómo funciona, dónde falla y cuándo puedes omitirlo.

Puntos clave

• El CDC copia cambios, no tablas completas, así que el destino sigue al origen con un pequeño retraso.
• Leer el log de la base de datos suele ser el método más confiable. Los triggers y el polling son más simples, pero tienen costos reales.
• Lo difícil es el orden, los duplicados y los cambios de esquema, no las herramientas.
• El CDC suele ser más seguro que la escritura dual, porque la base de datos de origen sigue siendo la única fuente de verdad.
• Para sistemas pequeños o con poco tráfico, una ventana de mantenimiento y una exportación simple pueden ser suficientes.

¿Qué es change data capture (CDC)?

El CDC convierte una base de datos en un flujo de eventos. Cada vez que cambia una fila, un registro describe lo que pasó: la tabla, la clave primaria, los valores anteriores, los valores nuevos y el tipo de operación.

Un consumidor lee ese flujo y aplica los cambios a un destino. El destino puede ser una base de datos nueva en otro motor, un índice de búsqueda, un data warehouse o una caché.

La idea clave es que la aplicación no necesita enterarse. Tu código escribe en la base de datos exactamente igual que antes, y la captura ocurre por debajo. Eso es lo que hace atractivo al CDC cuando te da miedo tocar una base de código legado.

Una configuración de CDC normalmente tiene dos fases:

1. Snapshot inicial: copiar los datos existentes al destino.
2. Streaming continuo: aplicar cada cambio hecho después de que empezó el snapshot.

Lograr que estas dos fases se encuentren sin huecos ni superposiciones es donde se concentra la mayor parte del cuidado de ingeniería.

¿Cómo funciona el CDC: logs, triggers o polling?

Hay tres enfoques comunes. Intercambian simplicidad por precisión y por carga sobre el origen.

CDC basado en log

Esto es lo que la mayoría de los equipos quiere decir con CDC. La base de datos ya registra cada cambio confirmado en su log para recuperarse de fallas y para la replicación. Un conector lee ese log y publica eventos. Herramientas open source como Debezium hacen esto para varias bases de datos populares, y los proveedores de nube ofrecen versiones administradas.

Triggers y polling

Los triggers sirven para un puñado de tablas. El polling sirve cuando solo te importan las filas que se crean o actualizan y confías en los timestamps. En una base de código heredada, no confío en ellos por defecto: scripts masivos, SQL directo y rutas de código antiguas pueden actualizar filas sin tocar la columna de timestamp, y normalmente no puedes descartarlo hasta haber leído todas las rutas de escritura.

¿Por qué usar CDC al migrar una plataforma en vivo?

Una migración en vivo tiene una restricción dura: el sistema antiguo sigue recibiendo escrituras hasta el día del cambio. Si copias los datos una sola vez, quedan desactualizados en el momento en que termina la copia.

El CDC resuelve esto manteniendo actualizada la base de datos nueva mientras construyes y pruebas el nuevo sistema con datos reales. Cuando tengas confianza, mueves el tráfico, y el cutover puede convertirse en un paso pequeño en lugar de un fin de semana de riesgo.

En avanzzada lideré la migración completa de una plataforma que postula automáticamente a ofertas de empleo por sus usuarios, llevando toda su arquitectura de un stack legado a uno nuevo mientras la gente la seguía usando todos los días. En ese tipo de trabajo, la pregunta nunca es solo cómo mover los datos. Es cómo lograr que dos sistemas cuenten la misma historia mientras usuarios reales cambian esa historia cada minuto.

Prefiero migrar pieza por pieza antes que hacer una reescritura big-bang por una razón simple: una reescritura suele costar más y tardar más, porque el sistema antiguo tiene que seguir funcionando en paralelo de todos modos. El CDC es una de las herramientas que hacen viable el camino incremental.

El CDC ayuda de algunas formas concretas:

• Pruebas realistas: el nuevo sistema funciona con datos frescos y con la forma de producción, no con un dump desactualizado.
• Traslado gradual del tráfico: puedes mover una funcionalidad o un grupo de usuarios a la vez, lo que encaja con un enfoque incremental en lugar de una reescritura big-bang.
• Rollback más fácil: mientras la base de datos antigua se mantiene actualizada, puedes devolver el tráfico si algo se ve mal.

¿Cuáles son los errores comunes: orden, duplicados y cambios de esquema?

Las herramientas están maduras. La mayoría de los problemas vienen de tres cuestiones que las herramientas no pueden ocultar del todo.

Orden

Los cambios en una misma fila deben aplicarse en el orden en que ocurrieron. Si una actualización del email de un usuario llega antes del insert que creó al usuario, el destino falla o queda con el valor equivocado.

Las herramientas basadas en log generalmente emiten los cambios en orden de commit, pero si distribuyes los eventos entre muchos consumidores en paralelo, puedes perder ese orden. Una regla común: particionar por clave primaria para que todos los cambios de una fila pasen por el mismo consumidor, en secuencia.

Duplicados

La mayoría de los pipelines de CDC están diseñados para entrega at-least-once. Eso significa que un evento puede llegar dos veces después de un reinicio o un reintento. Tu consumidor debe ser idempotente: aplicar el mismo cambio dos veces debe dar el mismo resultado que aplicarlo una vez.

Los upserts por clave primaria, junto con guardar la posición en el log del último cambio aplicado, son las defensas habituales.

Cambios de esquema

Alguien agrega una columna, renombra un campo o cambia un tipo en el origen mientras el pipeline está corriendo. Según la herramienta, el flujo puede romperse, descartar el campo nuevo o pasar algo que el destino no puede interpretar.

Planifica esto de forma explícita:

• Congela o revisa los cambios de esquema en el origen durante la migración.
• Prefiere cambios aditivos: agrega columnas nuevas antes de usarlas y elimina las antiguas solo después del cutover.
• Configura alertas para fallas y retrasos del pipeline, para que una detención silenciosa no se convierta en una sorpresa en el cutover.

Verificación

No supongas que el destino coincide. Compara conteos de filas, checksums de las tablas principales y revisiones puntuales de registros que involucran dinero, como pedidos, pagos y suscripciones. Ejecuta la comparación varias veces, no una sola.

Cuando me hago cargo de un sistema, mi orden es primero el acceso, luego el build, luego los flujos de dinero y luego los riesgos. Como trabajé en el equipo de carrito y checkout de Total Wine & More, reviso primero las tablas detrás del checkout y la facturación, porque ahí es donde una discrepancia silenciosa duele más.

CDC vs escritura dual: ¿cuál es más seguro?

La escritura dual significa que tu aplicación escribe en la base de datos antigua y en la nueva dentro de la misma ruta de código. Parece simple, y es tentador cuando controlas el código.

El problema es que dos bases de datos no pueden hacer commit de forma atómica sin un mecanismo adicional. Una escritura puede tener éxito mientras la otra falla, y entonces quedan en desacuerdo sin ningún registro del motivo. Las solicitudes concurrentes también pueden aplicar cambios en las dos bases de datos en órdenes distintos.

El CDC evita esto manteniendo una sola fuente de verdad. La aplicación escribe una vez, y los cambios fluyen hacia afuera desde el log confirmado. Si el pipeline falla, puede retomar desde su última posición y ponerse al día, siempre que el origen todavía conserve el log que necesita.

La escritura dual puede funcionar cuando el sistema es pequeño, puedes ver todas las rutas de escritura y una discrepancia breve es tolerable. Aun así, la combinaría con un job de reconciliación. Para cualquier cosa que toque pagos o datos de usuarios, elegiría CDC primero.

¿Cuándo change data capture es excesivo?

El CDC agrega piezas móviles: un conector, un flujo, consumidores y monitoreo. Alguien tiene que operarlos. Omítelo cuando:

• La base de datos es pequeña y una ventana de mantenimiento corta es aceptable.
• Los datos cambian rara vez, así que una exportación final justo antes del cutover lo captura todo.
• Solo necesitas una copia única, no sincronización continua.
• El equipo no tiene a nadie que pueda operar y monitorear el pipeline después del lanzamiento.

Una regla práctica simple de mi propia experiencia (una estimación, no un benchmark): si puedes explicar todas las rutas de escritura en una pizarra y el downtime es barato, prueba primero la opción simple. Si los usuarios escriben constantemente y el downtime no es una opción, el CDC justifica su costo.

¿Quieres una segunda opinión sobre tu migración?

Si estás planificando una migración y no sabes si el CDC encaja en tu caso, escríbeme a me@filipeeduardo.dev con una breve descripción de tu stack y de tu volumen de escritura. Con gusto comparo notas contigo y te digo qué revisaría primero.