Un proceso que consulta filas modificadas desde la última ejecución puede capturar altas y actualizaciones. Pero, si una fila desaparece físicamente y el origen no registra esa eliminación en otro lugar, la consulta ya no tiene nada que devolver. El destino conserva entonces un dato que dejó de existir.
La captura de cambios, o CDC, aborda ese problema mediante una fuente de eventos o cambios del sistema de origen. Sin embargo, disponer de un conector no garantiza que el destino interprete correctamente los borrados. Hay que diseñar su aplicación, el orden de procesamiento y la recuperación.
Define qué representa la tabla de destino
Antes de configurar el conector, aclara si el destino representa el estado actual, una historia de cambios o ambas cosas.
En una réplica de estado actual, un borrado confirmado debe dejar de aparecer como una fila activa. En una tabla histórica puede conservarse el evento de eliminación y cerrar la vigencia del registro, según las reglas de conservación y acceso acordadas. Esas dos representaciones sirven a usos diferentes.
El error habitual es tratarlas como si fueran la misma tabla. Un informe operativo puede contar como activos registros que solo se conservan como historia; una actualización puede destruir información que otro análisis necesita para reconstruir un periodo anterior.
Un recorrido mínimo con alta, cambio y borrado
Utilicemos este ejemplo construido para un catálogo. Los números de posición son etiquetas ilustrativas de secuencia, no offsets de un producto concreto.
| Posición | Clave | Operación | Contenido relevante |
|---|---|---|---|
| 101 | P-42 | Alta | Estado: disponible |
| 102 | P-42 | Actualización | Estado: retirado |
| 103 | P-42 | Borrado | La clave deja de existir en origen |
Después de aplicar la secuencia completa, una tabla de estado actual no debe mostrar P-42. Una historia de eventos debería permitir explicar que existió, cambió y se eliminó, siempre dentro de la política que corresponda.
Prueba primero este recorrido sin transformaciones complejas. Si el consumidor solo ejecuta inserciones y actualizaciones, puede procesar los dos primeros eventos y descartar el tercero. La ingesta parecerá saludable aunque el resultado sea incorrecto.
Diferencia el evento de borrado y el tombstone
No todos los mensajes relacionados con una eliminación tienen la misma función. En determinados conectores, un evento describe la operación de borrado y otro mensaje con valor nulo facilita la compactación del registro de mensajes.
El conector de Debezium para PostgreSQL documenta esa distinción: según su configuración, puede emitir un evento de borrado seguido por un tombstone con la misma clave. El consumidor debe entender el formato y las transformaciones intermedias que se hayan aplicado.
No elimines mensajes nulos de la canalización solo porque no contienen un objeto JSON completo. Primero verifica su significado. Tampoco interpretes cualquier campo nulo dentro de un registro como una orden de borrado: puede ser un valor legítimamente desconocido.
Guarda ejemplos reales de mensajes del conector elegido y descríbelos en el contrato de datos que comparte el consumidor. La documentación de otra herramienta no sustituye esa comprobación.
Evita que una actualización atrasada resucite un registro
Después de aplicar el borrado de P-42, imagina que el consumidor vuelve a recibir la actualización anterior. Si realiza un upsert sin comprobar el orden, el producto reaparece como retirado aunque ya no exista.
Una estrategia consiste en conservar la posición o versión aplicable a cada clave y rechazar cambios anteriores. Pero esa comparación debe utilizar un orden que el origen y el transporte realmente garanticen. Un timestamp de aplicación con baja precisión puede no ser suficiente, y posiciones de particiones diferentes no siempre son comparables.
Cuando se borra físicamente la fila del destino, también hay que decidir dónde queda la información necesaria para reconocer eventos antiguos. Puede mantenerse un registro de eliminación separado o conservar un estado marcado, según el modelo. Su conservación debe cubrir el escenario de reproducción que el sistema permite.
Otra posibilidad es garantizar el procesamiento ordenado por clave durante todo el recorrido y controlar desde qué punto se reinicia. Esa garantía debe incluir las colas, transformaciones y escrituras; no basta con que exista en el primer componente.
Relaciona la aplicación del cambio con el avance del consumidor
Si se confirma el progreso antes de escribir en el destino, un fallo puede hacer que el evento se considere procesado sin que su efecto exista. Si se escribe y el proceso se detiene antes de confirmar, el evento puede volver a recibirse.
Por eso el diseño debe tolerar repeticiones y relacionar el avance del consumidor con los cambios aceptados. Cuando ambas operaciones no se pueden confirmar en una sola transacción, se necesita una estrategia de recuperación y deduplicación coherente con las garantías disponibles.
En el ejemplo, repetir el borrado de P-42 debería producir el mismo estado final previsto. Una respuesta de “fila no encontrada” puede ser aceptable en esa repetición si el sistema puede demostrar que está aplicando la eliminación correcta.
La carga inicial y el flujo de cambios deben encajar
Una fotografía inicial copiada mientras el origen sigue cambiando necesita un punto de enlace con el flujo de eventos. Si se elige ese punto de forma incorrecta, puede haber huecos o cambios aplicados dos veces.
Comprueba cómo resuelve esta transición el conector utilizado y qué ocurre cuando la copia inicial se interrumpe. No fabriques una solución basada únicamente en la hora de inicio de la extracción si el origen ofrece posiciones transaccionales más precisas.
También hay que vigilar cuánto tiempo se conservan los cambios pendientes de leer. Si el consumidor queda detenido más allá de esa ventana, reanudarlo como si nada hubiera ocurrido puede dejar huecos. El procedimiento debe identificar esa situación y ejecutar la recuperación prevista, que puede requerir una nueva fotografía.
Una batería de aceptación centrada en el estado
Además del recorrido de alta, actualización y borrado, prueba un evento repetido, una actualización retrasada, una caída durante la escritura, un cambio de clave y una parada que agote la retención disponible.
En cada prueba compara el estado del destino con el resultado esperado. Los recuentos globales ayudan a detectar anomalías, pero dos tablas pueden tener el mismo número de filas y distintos registros. Utiliza conciliaciones por claves o particiones y controles de contenido adecuados al volumen.
Distingue retraso tolerable de divergencia permanente. Un borrado todavía pendiente puede ser compatible con la latencia acordada; un borrado descartado por el consumidor requiere corregir el proceso.
Si necesitas revisar una plataforma de integración y Big Data, plantea a Nexeus Big Data qué estado deben ver los consumidores y cómo se eliminan los registros en el origen. Es el punto de partida para diseñar CDC que también funcione cuando los datos desaparecen.