Idempotencia

Un proceso es idempotente si correrlo una vez y correrlo cinco veces dejan el almacén exactamente igual.

Suena a detalle técnico menor. Es lo que decide si a las 3 de la mañana, cuando un proceso truene a la mitad, puedes simplemente volver a correrlo o tienes que despertarte a limpiar a mano.

El caso que a todos nos pasa una vez

-- NO es idempotente: cada corrida agrega filas otra vez.
INSERT INTO analitica.ventas
SELECT * FROM crudo.ventas WHERE fecha = '2026-07-24';

El proceso corre, se cae en el paso siguiente, alguien lo reintenta y ahora el 24 de julio tiene el doble de ventas. El reporte del lunes está mal y nadie sabe por qué, porque técnicamente "no falló nada".

Las dos formas de arreglarlo

Borrar y volver a escribir la partición. Sencillo y suficiente casi siempre:

BEGIN;
DELETE FROM analitica.ventas WHERE fecha = '2026-07-24';
INSERT INTO analitica.ventas
SELECT * FROM crudo.ventas WHERE fecha = '2026-07-24';
COMMIT;

Ambas operaciones van en la misma transacción. Si algo revienta entre las dos, no te quedas con el día vacío.

Fusionar por llave (MERGE o upsert), cuando la fila puede llegar actualizada:

MERGE INTO analitica.clientes AS destino
USING crudo.clientes AS origen
  ON destino.id_cliente = origen.id_cliente
WHEN MATCHED THEN UPDATE SET
  correo = origen.correo,
  actualizado_en = origen.actualizado_en
WHEN NOT MATCHED THEN INSERT (id_cliente, correo, actualizado_en)
  VALUES (origen.id_cliente, origen.correo, origen.actualizado_en);

Dónde más aparece

En el orquestador, cada reintento automático asume que tu tarea es idempotente. En una API que recibe eventos, la misma notificación puede llegar dos veces por diseño —a eso se le llama entrega at-least-once—, y la única defensa es que procesarla dos veces no cambie nada.