La idempotencia es la mayor parte del trabajoLa idempotencia es la mayor parte del trabajo

Un pipeline se va a volver a ejecutar. No es que pueda pasar: pasará. La red se cae a mitad de camino, alguien corrige un error y recarga una semana, un operador no está seguro de que el proceso terminara y lo lanza otra vez.

La única pregunta real es qué ocurre la segunda vez. Si volver a ejecutar es seguro y aburrido, la mayoría de los problemas operativos se vuelven pequeños. Si no lo es, cada fallo se convierte en una investigación sobre el estado en que están los datos.

Añadir es la trampa

La carga más sencilla es un insert, y los inserts no son idempotentes. Ejecuta dos veces el fichero de ayer y ayer existe dos veces. Nada da error. El número de filas parece plausible. Los ingresos de un día se duplican sin hacer ruido, y lo descubre semanas después alguien que recuerda que aquel martes no fue tan bueno.

La solución es que la carga apunte a un estado y no a un evento: esta clave debe terminar con estos valores. Que sea un merge, un upsert o un delete-then-insert sobre una partición acotada importa menos que la propiedad: ejecutarlo dos veces deja el mismo resultado que ejecutarlo una.

Necesitas una clave que signifique algo

Hacer merge exige saber qué hace que una fila sea la misma fila. Un id sustituto generado al cargar no puede hacerlo; por definición es distinto en cada ejecución.

Así que necesitas una clave de negocio: un número de pedido, una referencia de transacción, una combinación del sistema de origen y el id de origen. Si el origen de verdad no tiene una clave estable, conviene decirlo pronto, porque cualquier estrategia de deduplicación aguas abajo será una conjetura construida sobre eso.

Si no puedes decir qué hace que dos filas sean la misma fila, no puedes hacer que la carga sea repetible. Todo lo que venga después es esperanza.

Las particiones abaratan las repeticiones

Aquí se encuentran la idempotencia y la carga incremental. Si los datos están particionados por día y una carga es dueña de su partición por completo, volver a ejecutar un día es trivialmente seguro: se sustituye la partición. Sin lógica de merge, sin emparejar claves, sin ambigüedad.

A menudo es el diseño correcto más sencillo, y vale la pena recurrir a él antes que a algo más ingenioso. Deja de funcionar cuando los registros cambian de partición a posteriori, como una corrección tardía de un pedido antiguo, que es justo cuando sí necesitas el merge.

El beneficio operativo

Cuando volver a ejecutar es seguro, el procedimiento de recuperación para casi todo pasa a ser el mismo: ejecutarlo otra vez. Los backfills dejan de ser especiales. Un proceso fallido a las 3 de la madrugada puede esperar a la mañana. Un operador nervioso que hace clic dos veces no es un incidente.

Por eso merece la pena dedicarle tiempo de diseño desde el principio. No porque sea elegante, sino porque convierte toda una categoría de problemas de las 3 de la madrugada en una categoría de problemas corrientes.