Cuando dos sistemas guardan el mismo dato, tarde o temprano discrepan. Esta guía trata sobre cómo diseñar la sincronización para que eso no ocurra.
Definir la fuente de verdad antes de escribir código
Para cada dato compartido debe existir un sistema que manda. Si dos sistemas pueden modificar el mismo campo, hace falta una regla explícita de resolución de conflictos, y esa regla es una decisión de negocio, no técnica.
La mayoría de problemas de calidad de datos en integraciones se originan aquí: nadie definió quién manda, y ambos lados escriben.
Idempotencia: el requisito que evita los desastres
Un proceso idempotente produce el mismo resultado si se ejecuta una vez o cinco. Es lo que permite reintentar sin miedo cuando un proceso falla a mitad de camino.
En la práctica significa usar identificadores estables del origen y operaciones de inserción-o-actualización, en lugar de inserciones ciegas que duplican registros en cada reintento.
Incremental frente a completo
La carga completa es simple y robusta, pero inviable con volúmenes grandes. La incremental es eficiente pero necesita una marca fiable de cambio: una fecha de modificación mantenida por el origen o un registro de cambios.
El patrón que funciona en la práctica es incremental de forma habitual y una reconciliación completa periódica, que detecta las divergencias que el proceso incremental haya podido acumular.
Qué hacer con los registros que fallan
Detener todo el proceso porque un registro está mal formado es una mala estrategia: un dato defectuoso bloquea miles de correctos. Descartarlo en silencio es peor.
La solución es apartar los registros problemáticos en una cola de revisión, continuar con el resto y reportar el conteo. Lo que no se mide se acumula: un proceso que descarta el dos por ciento sin avisar produce, en un año, una divergencia sustancial que nadie sabe explicar.