¿Qué es change data capture y en qué se diferencia el CDC basado en log de sondear una columna de timestamp?

Change data capture emite en streaming los cambios a nivel de fila de una base de datos origen. El CDC basado en log lee directamente el log de transacciones, así que captura inserciones, actualizaciones y borrados definitivos en orden de commit y casi sin carga sobre el origen. Sondear una columna updated_at es más simple pero se pierde los borrados definitivos, se pierde los estados intermedios entre sondeos, depende de que la aplicación mantenga la columna y puede saltarse filas por problemas de reloj o de frontera de transacción.

El CDC va de obtener cambios a nivel de fila en lugar de releer tablas enteras. El CDC basado en log, con algo como Debezium leyendo el write ahead log de Postgres o el binlog de MySQL, te da cada inserción, actualización y borrado en orden de commit y casi no pone carga de consultas sobre la primaria. Sondear una columna updated_at es mucho más fácil de montar, y está bien para datos de referencia que cambian poco, pero tiene agujeros reales. No puede ver los borrados definitivos en absoluto, así que las filas persisten aguas abajo en silencio para siempre. Se pierde estados intermedios si una fila cambia dos veces entre sondeos, y depende de que todos los escritores se acuerden de poner la columna, cosa que un job heredado de nuestro parque nunca hizo. El CDC basado en log tiene su propio coste operativo. Necesitas un slot de replicación, y si tu consumidor se atasca el log no se libera y el disco del origen se llena, que es un fallo genuinamente peligroso. Así que monitorizo el retraso del slot como una alerta de primera clase junto al retraso del pipeline.