Una carga puede fallar después de guardar los datos y antes de comunicar que ha terminado. Si el siguiente intento vuelve a insertar las mismas filas, un incidente de conexión acaba convertido en pedidos duplicados, métricas infladas y horas de conciliación.
La idempotencia permite repetir una operación y conservar el mismo resultado de negocio que si se hubiera ejecutado una vez. No significa que la tarea se ejecute una sola vez, ni que baste con activar los reintentos del orquestador. Hay que diseñar cómo se identifica cada dato y cómo se confirma su escritura.
Un ejemplo: el pedido llega dos veces
Supongamos una integración ficticia entre un ERP y un almacén analítico. El pedido P-1042 contiene dos líneas. El pipeline guarda ambas, pero pierde la conexión antes de registrar la finalización.
| Decisión de diseño | Qué ocurre al repetir la carga |
|---|---|
| Insertar cada fila con un identificador nuevo | Aparecen cuatro líneas en lugar de dos |
| Usar solo el identificador de pedido como clave | Una línea puede sobrescribir a la otra |
| Usar pedido y número de línea como clave | Cada línea conserva una identidad estable |
La clave debe representar el grano del dato: qué significa exactamente una fila. Una restricción de unicidad puede impedir duplicados, pero el proceso también tiene que gestionar el conflicto y reconocer una repetición válida.
Fija qué datos estás reprocesando
Reintentar una carga de ayer leyendo «los últimos datos disponibles» mezcla recuperación y actualización. Si el origen cambió, el resultado ya no corresponde necesariamente al mismo lote.
Conserva una referencia estable: un archivo versionado, una partición, un snapshot o un intervalo con reglas explícitas para las correcciones. Registra también la versión de la transformación. Así podrás distinguir una repetición del trabajo original de un recálculo deliberado.
La documentación de buenas prácticas de Apache Airflow recomienda resultados repetibles, lecturas y escrituras sobre particiones concretas y evitar inserciones que generen duplicados al reejecutarse.
Confirma el resultado, no solo el final del programa
En el ejemplo, una operación de actualización o inserción por clave puede resolver las repeticiones. Sin embargo, un UPSERT no basta si un evento antiguo sobrescribe una versión más reciente. El destino necesita una regla sobre qué versión prevalece y cómo se tratan los borrados.
Cuando la carga reemplaza una partición completa, otro enfoque es preparar el resultado en una zona temporal, verificarlo y publicarlo mediante una operación atómica que soporte el destino. El lector no debería encontrar media partición antigua y media nueva.
El punto decisivo es el fallo entre la escritura y la confirmación. El reinicio debe consultar evidencia persistida o repetir una operación segura; una variable en memoria no sobrevivirá a la caída del proceso.
Una prueba pequeña que descubre fallos importantes
Antes de aceptar la integración, prueba estas situaciones con datos controlados:
- Ejecuta el mismo lote dos veces y compara las claves y valores resultantes.
- Interrumpe la ejecución después de escribir, pero antes de confirmar el éxito.
- Envía una versión antigua después de una corrección reciente.
- Repite un evento de borrado y verifica que el registro no reaparece.
- Lanza dos intentos simultáneos y comprueba el comportamiento de los conflictos.
Compara el estado de negocio, no todos los campos técnicos: una marca de «último intento» puede cambiar legítimamente. Un conteo idéntico tampoco demuestra que los importes o estados sean correctos.
Revisa los efectos fuera del almacén
Un pipeline puede actualizar una tabla y enviar después un correo, crear un ticket o invocar una API. La idempotencia de la tabla no protege automáticamente esas acciones. Cada efecto necesita su propia identidad y mecanismo de confirmación, o un registro de entregas que permita reconciliar lo sucedido.
En una revisión de ingeniería de datos, conviene comenzar por una pregunta concreta: «¿Qué ocurre si este paso se ejecuta dos veces?». Si la respuesta depende de que nunca falle la red, todavía queda una decisión de diseño pendiente.
Para revisar un flujo concreto con Nexeus Big Data, describe el origen, el destino y el punto de fallo. Esa información permite delimitar el problema antes de proponer una solución.