Por Andrew Tan
Change Data Capture es la capa invisible que habilita los análisis en tiempo real y los sistemas basados en eventos, pero la mayoría de los equipos solo piensan en ella después de su primer incidente en producción.
La capa invisible de la que todo depende
Cuadros de mando en tiempo real. Microservicios basados en eventos. Lagos de datos que se mantienen actualizados. Detrás de cada una de estas arquitecturas modernas de datos se encuentra un componente en el que la mayoría de los equipos no piensa demasiado: Change Data Capture.
La función de CDC es bastante simple: observar los registros de transacciones de la base de datos y emitir eventos cada vez que los datos cambian. ¿Un pedido nuevo? Evento. ¿Actualización de estado? Evento. ¿Eliminación de un cliente? Evento. El concepto es elegante y, cuando funciona, simplemente funciona.
Pero hay un problema. CDC es la fontanería de la infraestructura moderna de datos: invisible cuando funciona, catastrófica cuando falla y, de alguna manera, siempre una idea de último momento en las revisiones de arquitectura. Los equipos pasan semanas debatiendo topologías de Kafka y configuraciones de Spark, para luego agregar un conector CDC con la configuración predeterminada y seguir adelante.
Seis meses después, llega la llamada. El cuadro de mando lleva seis horas de retraso. La sincronización de inventario muestra los datos de ayer. El CEO pregunta por qué los clientes pueden comprar productos que no existen. Y nadie logra entender por qué, porque el conector CDC está "saludable" según el panel de monitoreo.
Este patrón se repite en toda la industria con una consistencia notable. El problema no es que CDC sea fundamentalmente poco confiable. Es que la brecha entre lo que los equipos asumen que hace y lo que realmente hace es lo suficientemente amplia como para ocultar incidentes en producción hasta que se convierten en problemas de negocio.
Lo que CDC hace realmente (y lo que los equipos asumen que hace)
En su núcleo, Change Data Capture observa el registro de transacciones de tu base de datos y emite eventos cada vez que los datos cambian. ¿Insertar una fila? Evento. ¿Actualizar un campo? Evento. ¿Eliminar un registro? Evento. El concepto es bellamente simple.
Pero la simplicidad es engañosa. Esto es lo que CDC realmente captura frente a lo que los equipos asumen que captura:
| Lo que los equipos asumen | Lo que realmente ocurre |
|---|---|
| "Cada cambio se captura inmediatamente" | Hay latencia. A veces milisegundos, a veces segundos, a veces más si el conector está rezagado. |
| "Los eventos están en el mismo orden que las transacciones" | No necesariamente. La replicación paralela, el orden de confirmación y la consistencia eventual pueden alterar las secuencias. |
| "Los cambios de esquema se manejan sin problemas" | ¿Agregar una columna? Bien. ¿Renombrar una? ¿Eliminar una? ¿Cambiar un tipo? Tu canalización de CDC puede necesitar intervención manual. |
| "Es solo leer el log, ¿qué podría salir mal?" | Caídas del conector, agotamiento de slots de replicación, problemas de espacio en disco en la base de datos de origen, particiones de red... |
La brecha entre la asunción y la realidad es donde nacen los incidentes.
Los tres modos de fallo de los que nadie habla
Después de ver una docena de implementaciones de CDC salir mal, he notado tres patrones de fallo que no reciben suficiente atención en los tutoriales y demostraciones de los proveedores.
1. La trampa de la deriva del esquema
El equipo de aplicaciones agrega una nueva columna a la tabla orders. Es un cambio inofensivo: un campo nullable delivery_notes. Lo despliegan el martes. Para el jueves, tu almacén de datos tiene registros incompletos porque el conector CDC sigue usando el esquema anterior y descarta silenciosamente el campo nuevo.
¿Lo peor? El conector no falla. Simplemente produce eventos que son técnicamente válidos pero prácticamente incorrectos. Tus monitores de calidad de datos no lo detectan porque el validador de esquemas cree que todo está bien. Solo descubres la brecha cuando alguien pregunta por qué el informe de notas de entrega está en blanco durante la mitad de la semana.
2. La bomba del slot de replicación
Usuarios de PostgreSQL, este es para ustedes. Los conectores CDC usan "replication slots" para rastrear qué entradas de WAL (Write-Ahead Log) han procesado. Si tu conector se cae — o incluso solo se ralentiza significativamente — esos slots retienen las entradas del log. La base de datos no puede reclamar ese espacio en disco.
He visto equipos despertarse con bases de datos de producción al 95 % de capacidad de disco porque un conector CDC inestable mantenía los slots de replicación como rehenes. La solución es un trabajo de limpieza manual que da terror ejecutar a las 2 AM. ¿La prevención? Monitoreo y alertas que la mayoría de los equipos no configuran hasta después del primer incidente.
3. El problema del acoplamiento del consumidor
CDC emite un torrente de eventos. Cada microservicio, trabajo de análisis y sincronización de almacén de datos que se preocupa por los cambios en la base de datos se conecta a ese flujo. Es elegante y desacoplado — hasta que deja de serlo.
¿Qué ocurre cuando un consumidor lento no puede seguir el ritmo? La backpressure se propaga. El conector CDC pone en búfer, luego descarta y luego se cae. O peor: sigue ejecutándose pero se retrasa, y tu canalización "en tiempo real" tiene un retraso de 20 minutos que nadie nota porque el panel de métricas muestra "conector saludable".
La solución suele ser alguna forma de almacenamiento en búfer (Kafka, Kinesis, una cola de mensajes) entre la fuente CDC y los consumidores. Pero ahora has agregado latencia y otra pieza de infraestructura que administrar. La fontanería simple se ha convertido en un subsistema complejo.
Dimensionar para la realidad, no para la esperanza
Aquí hay una conversación ficticia:
Yo: "¿Cuántas transacciones por segundo debe manejar tu CDC?"
Ellos: "Oh, tal vez unos pocos cientos en el pico."
Yo: "¿Y cuál es tu tabla más grande?"
Ellos: "Unos cincuenta millones de filas."
Yo: "¿Qué ocurre cuando ejecutas una actualización masiva en esa tabla?"
Ellos: "...A veces hacemos eso."
Los conectores CDC no se dimensionan para el volumen promedio de transacciones. Se dimensionan para el volumen de transacciones del peor caso. Ese trabajo trimestral de limpieza de datos que toca diez millones de filas genera diez millones de eventos CDC de golpe. Si tu conector no puede manejar el pico, obtienes retraso, backpressure o eventos perdidos.
Los equipos que lo hacen bien planifican los picos desde el primer día. Configuran monitoreo sobre el retraso de replicación, no solo la salud del conector. Prueban sus modos de fallo: ¿qué ocurre si el conector se reinicia en medio de una actualización masiva? ¿Qué ocurre si el destino está caído durante una hora?
Decisiones de diseño que hacen que CDC sea manejable
CDC no tiene que ser una bomba de tiempo. Estos son los patrones que he visto funcionar en producción:
Separar la infraestructura CDC de la infraestructura de análisis
No ejecutes tu conector CDC en el mismo clúster que tus trabajos de Spark o tus consultas de BI. Cuando el equipo de análisis ejecuta una unión pesada que satura la red, tus eventos CDC no deberían sufrir. Dale a CDC su propio carril.
Los consumidores idempotentes son innegociables
Los eventos CDC pueden duplicarse. Los conectores se reinician, ocurren particiones de red, la entrega al menos una vez es el valor predeterminado. Si tu consumidor downstream no puede manejar "procesar esta actualización de pedido dos veces", vas a tener corrupción de datos. Construye la idempotencia desde el inicio.
Los registros de esquema salvan la cordura
Usa un registro de esquema (Confluent Schema Registry, AWS Glue o similar) para rastrear cambios en los esquemas de tus eventos. Cuando el equipo de aplicaciones cambia una tabla, el cambio de esquema fluye a través del registro y tus consumidores pueden adaptarse programáticamente en lugar de romperse en silencio.
Monitorea lo que importa
"El conector está ejecutándose" es la métrica equivocada. Monitorea:
- Retraso de replicación (¿qué tan atrás está el CDC de la base de datos?)
- Tasa de procesamiento de eventos (¿estamos siguiendo el ritmo de producción?)
- Eventos de cambio de esquema (¿cambió algo en la fuente que debamos saber?)
- Profundidad de la cola de mensajes fallidos (¿qué no se pudo procesar y por qué?)
Dónde encaja layline.io: CDC sin trampas ocultas
En layline.io, hemos visto a los equipos luchar con CDC hasta el punto de que construimos un Debezium Source Asset dedicado directamente en la plataforma. El objetivo no es reinventar CDC — Debezium es excelente — sino envolverlo en la confiabilidad y observabilidad que los sistemas de producción necesitan.
En lugar de ejecutar un conector independiente que debas vigilar constantemente, layline.io te ofrece:
Diseño visual de canalizaciones que incluye fuentes CDC como ciudadanos de primera clase. Ves el flujo de datos de la base de datos al destino en un solo lienzo. Cuando algo se rompe, sabes exactamente dónde.
Manejo integrado de backpressure a través del streaming del modelo de actores de Apache Pekko. Cuando los sistemas downstream se ralentizan, layline.io regula la velocidad con elegancia en lugar de descartar eventos o dejar que los conectores se caigan.
Manejo unificado de reintentos y errores en toda la canalización. Los eventos CDC que no pueden procesarse no desaparecen en un archivo de log; pasan por los mismos mecanismos de reintento que cualquier otra fuente de datos.
Transformación consciente del esquema que puede adaptarse a los cambios en la base de datos de origen sin intervención manual. Agregar una columna, renombrar un campo, cambiar un tipo: la canalización se ajusta en lugar de romperse.
La idea más amplia: CDC es demasiado importante como para ser una idea de último momento. Merece el mismo rigor de ingeniería que el resto de tu infraestructura de datos. Ya sea que uses layline.io o construyas tu propia pila, trata a CDC como el componente crítico que es, no como una fontanería que puedes ignorar hasta que el sótano se inunde.
Andrew Tan es un emprendedor en serie y fundador de layline.io, donde construye infraestructura empresarial de procesamiento de datos que maneja tanto cargas de trabajo por lotes como en tiempo real a escala.
