Todo ingeniero de datos vive, tarde o temprano, la misma pesadilla: un pipeline falló en mitad de la noche, alguien lo volvió a correr para recuperar, y por la mañana los informes muestran ventas duplicadas. No hubo más ventas — hubo datos duplicados porque el pipeline se corrió dos veces. Este problema tiene nombre y tiene solución: se llama idempotencia, y es quizás la propiedad más importante y menos hablada de un pipeline fiable.
Qué es la idempotencia
Un proceso es idempotente cuando correrlo una vez o varias veces produce exactamente el mismo resultado. Cargar los datos de un día debería dejar la base de datos en el mismo estado, ya corras esa carga una vez, ya la corras cinco veces por error. Si la segunda carga duplica los datos, el pipeline no es idempotente — y es una bomba de tiempo esperando el día en que alguien tenga que repetirlo.
Por qué esto importa más de lo que parece
En un mundo perfecto, cada pipeline corría una vez y nunca fallaba. En el mundo real, fallan — una conexión se cae, una fuente se retrasa, un servidor se reinicia — y la respuesta natural es volver a correrlo. Si el pipeline no es idempotente, cada recuperación crea un problema nuevo. Y como los fallos ocurren siempre en los peores momentos, la duplicación se descubre tarde, ya contaminada en informes y decisiones. La idempotencia es la red de seguridad que hace la recuperación segura en vez de peligrosa.
El patrón más común: borrar y reinsertar
La forma más simple y robusta de garantizar la idempotencia es el patrón "delete-insert" por partición. En vez de añadir a ciegas los datos nuevos, el pipeline primero borra los datos del período que va a cargar (por ejemplo, los de hoy) y solo después los inserta. Así, correr la carga de hoy dos veces deja siempre exactamente un conjunto de datos de hoy — la segunda carga borra lo que la primera puso y vuelve a poner lo mismo. Simple, predecible, a prueba de repeticiones.
La alternativa: upsert por clave
Cuando no hay una partición limpia por período, se usa el "upsert": para cada registro, si ya existe (identificado por una clave única), se actualiza; si no existe, se inserta. El resultado es el mismo — correr dos veces no duplica, porque la segunda pasada solo reescribe encima lo que ya estaba. Exige tener claves fiables, pero da idempotencia incluso en flujos donde los datos llegan mezclados.
Cuidados que marcan la diferencia
- Definir la granularidad correcta: la partición a borrar y reinsertar debe corresponder a lo que el pipeline procesa cada vez — ni de más (borras datos que no debías), ni de menos.
- Hacer la operación atómica: el borrar y el insertar deben ocurrir como un todo, para que un fallo a mitad no deje la base en un estado inconsistente.
- Pensar en los datos aguas abajo: si otros procesos leen estos datos, la sustitución debe ser invisible para ellos — no pueden atrapar el momento en que los datos están borrados pero aún no reinsertados.
Un caso concreto
Una empresa tenía un pipeline nocturno que añadía las ventas del día a la tabla histórica. Funcionó durante meses — hasta la noche en que la fuente se retrasó, el pipeline falló a mitad, y el equipo de operaciones, siguiendo el procedimiento, lo volvió a correr. Al amanecer, las ventas del día anterior aparecían duplicadas, y como la duplicación no era obvia (los totales solo parecían "un buen día"), tardó hasta que alguien desconfió. La corrección implicó identificar y borrar los registros duplicados a mano, con el riesgo de borrar los equivocados. Tras este susto, reescribieron el pipeline con el patrón delete-insert por día. La siguiente vez que falló y tuvo que repetirse, no pasó absolutamente nada — los datos quedaron correctos, sin intervención. El costo de hacer el pipeline idempotente se pagó en la primera recuperación tranquila.
La idempotencia es una mentalidad, no un truco
El verdadero valor no está en una técnica específica, sino en el hábito de diseñar cada pipeline pensando "¿y si esto corre dos veces?". Esa pregunta, hecha al inicio, cambia la arquitectura para mejor y ahorra noches en vela después. Los pipelines idempotentes se recuperan solos, toleran fallos sin drama y dan a quien los opera la tranquilidad de poder repetir sin miedo. Es la diferencia entre un sistema frágil y uno robusto.
En la práctica
Haz un ejercicio simple con tu pipeline más crítico: si lo corrieras ahora, otra vez, sobre datos que ya procesó, ¿qué pasaría? Si la respuesta es "duplicaría" o "no sé", encontraste tu próxima mejora — y probablemente evitaste una pesadilla futura. ¿Tus pipelines aguantan ser corridos dos veces, o viven esperando el día en que alguien tenga que repetirlos?
