Un backfill puede completar datos que faltan en un sistema conectado, pero también puede repetir acciones que no se limitan a guardar registros. Antes de ejecutarlo, conviene definir qué se reprocesará, cuál es el sistema de referencia y qué efectos secundarios podrían activarse. La meta no es simplemente enviar datos antiguos: es corregir una diferencia verificable sin desordenar la operación actual.
Backfill, migración y reintento: tres trabajos distintos
Un backfill vuelve a procesar un conjunto delimitado de datos históricos para completar o corregir información en un sistema conectado. Por ejemplo, puede enviar registros anteriores a una fecha en la que se activó una integración, o completar un campo que antes no se transmitía.
Una migración, en cambio, traslada datos entre sistemas o cambia su estructura, modelo o destino. Puede incluir un backfill como parte del trabajo, pero normalmente abarca decisiones adicionales sobre transformación, correspondencia de campos y coexistencia entre sistemas. Un reintento de eventos fallidos vuelve a procesar operaciones concretas que no se completaron, normalmente identificadas por un error o una cola pendiente. No equivale a recorrer todo el histórico.
La diferencia ayuda a escoger la solución. Si faltan registros porque nunca se enviaron, puede hacer falta un backfill. Si el sistema receptor conserva los datos y solo debe cambiar su estructura, se trata de una migración. Si hay eventos con errores conocidos, primero conviene resolverlos y reintentarlos, en vez de volver a enviar todos los registros históricos.
Decidir si reprocesar es la opción correcta
Antes de diseñar el proceso, formula el problema como una discrepancia observable: qué dato falta, dónde debería estar y desde cuándo. Si el origen contiene el valor correcto y el destino no, el backfill puede ser apropiado. Si el valor está mal en el origen, enviar ese mismo valor solo replicará el problema; primero hay que corregirlo allí o definir una transformación explícita.
También puede bastar con sincronizar el estado actual. Si el destino solo necesita conocer el estado vigente y no conservar cada cambio histórico, enviar todos los estados intermedios añade complejidad sin necesariamente aportar valor. En cambio, si se requieren eventos para auditoría, trazabilidad o cálculos, puede ser importante conservar el orden y el detalle histórico.
- Conviene hacer un backfill cuando existen registros elegibles y comprobables que no llegaron al destino, o cuando una regla de integración dejó campos incompletos.
- Conviene corregir el origen cuando el dato de referencia es incorrecto o incompleto antes de transferirlo.
- Conviene reintentar eventos cuando el problema está limitado a operaciones fallidas identificables y el mecanismo permite reanudarlas.
- Conviene sincronizar el estado actual cuando el destino no necesita reproducir el historial de cambios.
Evalúa además el impacto operativo. Un registro puede provocar una notificación, una actualización visible para un usuario, una asignación de tarea o una operación financiera. Si no puedes determinar qué acciones se activarán, no empieces con el histórico completo.
Delimitar registros y definir la referencia
Especifica el conjunto de datos con reglas que otra persona pueda repetir. Define fechas y zona horaria, estados incluidos, tipos de registro, exclusiones y condiciones de elegibilidad. Aclara si el límite temporal usa la fecha de creación, la de actualización o la de ocurrencia del evento: no son necesariamente equivalentes.
Identifica también la clave que vincula cada registro entre sistemas. Una clave estable permite reconocer si el destino ya contiene el objeto y decidir si corresponde crear, actualizar, omitir o revisar. No asumas que dos registros son el mismo solo porque comparten un nombre o una dirección; usa los identificadores definidos por la integración y comprueba cómo se tratan los valores ausentes o repetidos.
Designa un sistema de referencia para cada campo. El origen puede ser autoridad para el correo, mientras que el destino controla otro atributo. Sin esta decisión, un backfill podría sobrescribir cambios legítimos realizados en el receptor. Documenta qué campos se escriben, cuáles se preservan y qué hacer ante conflictos.
Elegir el mecanismo y proteger los efectos secundarios
Una carga por lotes puede ser adecuada cuando se busca transferir un conjunto conocido y el receptor admite importaciones controladas. Una API permite procesar registros con validaciones y respuestas por elemento, aunque exige gestionar límites, fallos y reanudación. La reproducción de eventos resulta útil si el historial de cambios importa y existe una forma segura de identificar eventos ya procesados. Ninguna opción es automáticamente mejor: el criterio es qué garantías ofrece sobre orden, duplicados, errores y observabilidad.
Antes de enviar, comprueba si la operación es idempotente: repetir la misma solicitud, con la misma clave, debería evitar crear un segundo efecto no deseado. Si no lo es, define cómo detectar duplicados y cómo recuperar una interrupción sin comenzar desde cero. Usa identificadores de operación o marcas de progreso cuando el sistema lo permita, y conserva un registro de qué se intentó y cuál fue la respuesta.
Separa la escritura del dato de los efectos asociados cuando sea posible. Por ejemplo, un modo de importación sin notificaciones o una regla temporal de supresión puede reducir el riesgo, siempre que esté disponible y aprobada. Si hay cobros, comunicaciones o cambios de estado irreversibles, establece controles explícitos antes de procesar. No confíes en que una actualización histórica será tratada como una actualización rutinaria.
El orden también puede cambiar el resultado. Si hay relaciones entre registros o cambios sucesivos, determina si deben procesarse primero los elementos principales y luego sus dependencias, o si cada cambio debe respetar su secuencia temporal. Si solo importa el estado final, deja esa regla escrita y evita reproducir transiciones que puedan disparar acciones.
Ensayar, ejecutar por etapas y detenerse a tiempo
Haz una prueba con una muestra representativa: incluye distintos estados, fechas, casos incompletos y situaciones con posibles duplicados. Compara el resultado esperado con el comportamiento real del destino, incluidos los efectos secundarios. Una muestra solo de registros sencillos puede ocultar los casos que más riesgo tienen.
Acuerda métricas antes de empezar: registros seleccionados, procesados, creados, actualizados, omitidos y fallidos. Define también cómo medir la diferencia entre origen y destino. Las cifras deben referirse al mismo conjunto y a la misma regla de elegibilidad; comparar totales generales puede confundir registros excluidos con pérdidas.
Ejecuta en etapas: primero una muestra pequeña, después un tramo acotado y, solo si los resultados son aceptables, el resto. Asigna a una persona responsable de vigilar el proceso y establece condiciones de parada, como una tasa de errores fuera del umbral acordado, duplicados inesperados, aumento de efectos secundarios o discrepancias crecientes. Detenerse debe ser una decisión prevista, no una improvisación.
Para reanudar, conserva el punto de progreso y separa los fallos recuperables de los que requieren intervención. Corrige la causa antes de reintentar; de lo contrario, el mismo error se repetirá. Una reversión no siempre es posible, especialmente si se enviaron comunicaciones o se ejecutaron acciones externas. Por eso, define de antemano si el plan consiste en restaurar datos, compensar efectos o detener nuevas escrituras mientras se investiga.
Conciliar y cerrar el trabajo
Al terminar, compara los registros esperados con los resultados del destino usando las claves acordadas. Clasifica las diferencias: registros no elegibles, errores técnicos, conflictos de datos y casos que requieren revisión manual. No declares éxito solo porque el proceso terminó sin interrupciones; debe haber una conciliación que explique las discrepancias.
Documenta el alcance ejecutado, las exclusiones, los errores pendientes, las decisiones sobre conflictos y cualquier efecto secundario observado. Conserva suficiente información para que soporte y operación puedan responder preguntas posteriores. Si la diferencia proviene de datos que siguen cambiando, define cómo se capturarán las modificaciones ocurridas durante el backfill para no dejar una nueva brecha.
Checklist antes de producción
- ¿Está claro qué diferencia se corrige y por qué no basta con un reintento o una sincronización del estado actual?
- ¿Están definidos fechas, estados, exclusiones, identificadores y sistema de referencia por campo?
- ¿Se comprobó el comportamiento ante duplicados, repetición de solicitudes y fallos parciales?
- ¿Se conocen y controlan notificaciones, cobros, cambios de estado y otras acciones activadas?
- ¿La muestra de prueba cubrió casos representativos y se verificó en el destino?
- ¿Hay métricas, responsable operativo, condiciones de parada y un plan de recuperación?
- ¿Existe un método de conciliación y una lista de diferencias que pueden requerir revisión?
Si alguna respuesta clave es desconocida, limita el alcance y resuelve esa incertidumbre antes de escalar. Un backfill seguro depende menos de procesar rápido que de poder explicar qué se envió, qué cambió, qué quedó pendiente y cómo se evitará repetir efectos no deseados.