Que un pipeline termine sin errores solo demuestra que terminó sin errores. No demuestra que haya procesado todo, que el resultado sea coherente ni que podamos repetirlo con seguridad.
El caso es que la fiabilidad no depende de una única prueba final. Surge de varias propiedades distintas que conviene hacer explícitas y tener presentes durante todo el proceso. Estas cinco comprobaciones forman un punto de partida pequeño, pero suficientemente exigente para descubrir muchos fallos que podrían llegar a producción —pasa con más frecuencia de lo que parece— como datos aparentemente válidos.
1. Alcance: ¿procesamos exactamente lo previsto?
El primer control no debe ser solo contar filas al final, sino definir el conjunto que debía entrar: una fecha de corte, una partición, un intervalo de claves o una versión del origen. Sin esa frontera, un contador no distingue entre una ejecución completa y otra que leyó correctamente solo una parte.
Es conveniente registrar el alcance junto con un identificador de ejecución y comparar registros esperados, leídos, transformados, escritos y rechazados. La ecuación no siempre será una igualdad simple, pero cualquier diferencia debe tener una causa identificable.
2. Invariantes: ¿se siguen cumpliendo las reglas esenciales?
Un esquema confirma tipos y campos; no necesariamente confirma significado. Claves únicas, relaciones válidas, rangos permitidos, orden temporal o coherencia entre importes son invariantes del dominio y deben comprobarse de forma explícita.
3. Reconciliación: ¿origen y destino cuentan la misma historia?
Comparar únicamente el número de registros puede ocultar duplicados, pérdidas que se compensan entre sí o transformaciones incorrectas. Una reconciliación razonable combina conteos con controles sobre claves, totales, estados o agregados relevantes.
La selección depende del riesgo que exista. En un flujo financiero, por ejemplo, tendrá sentido reconciliar importes; en una dimensión, claves y vigencias; en eventos, ventanas temporales y duplicados. Lo importante es que el criterio se defina antes de observar el resultado.
4. Idempotencia: ¿podemos repetir la ejecución sin empeorar el estado?
Los reintentos son normales: una conexión cae, alguna etapa termina a medias o una ejecución necesita reconstruirse. Repetir la misma entrada no debería crear copias, perder actualizaciones ni producir un resultado distinto sin una razón explícita.
Una clave estable y una escritura mediante upsert ayudan, pero no resuelven todo. También hay que decidir el punto de control, el comportamiento ante lotes parciales y qué versión de la entrada se está repitiendo.
5. Observabilidad: ¿el proceso mismo es capaz de explicar qué ocurrió?
Un mensaje de «ejecución correcta» aporta poco cuando aparece una diferencia horas después. Cada ejecución debería dejar, como mínimo, su alcance, duración por etapa, contadores, rechazos, punto de control y una causa de error que conserve contexto.
Observar no consiste en acumular logs. Consiste en poder responder con rapidez qué se procesó, qué quedó fuera, dónde cambió el comportamiento y si el resultado puede utilizarse con confianza.
El criterio de salida
Finalmente, es crucial que estas comprobaciones terminen en una decisión: aceptar la ejecución, aceptarla con rechazos controlados o invalidarla. Si todas las señales se registran pero ninguna modifica el resultado operativo, seguimos teniendo información, no control.
La fiabilidad no aparece al final del desarrollo. Se diseña junto con el pipeline, convirtiendo sus supuestos en condiciones que se puedan comprobar y explicar.