BlogConflictos de datos
Sincronizar datos: decidir qué hacer cuando dos personas cambian lo mismo
Recibir ambos cambios no decide cuál debe usar el negocio. Acuerda reglas por campo y conserva lo que necesita revisión.
Hoja de prueba: Sincronización de datos: reglas para conflictos
Recibir ambos cambios no decide cuál debe usar el negocio. Acuerda reglas por campo y conserva lo que necesita revisión. Registra datos, resultado esperado, evidencia, responsable y resultado observado.
Cada campo necesita una regla adecuada
Una nota adicional puede agregarse sin sustituir otra; un precio negociado no siempre puede reemplazarse por el más reciente. Clasifica campos que admiten combinación, campos con una fuente autorizada y campos que requieren revisión. En inventario, los movimientos y ajustes necesitan su propia regla: sincronizar un saldo absoluto no equivale a registrar todas las entradas y salidas.
CouchDB explica que una revisión seleccionada por su algoritmo puede ocultar otras revisiones en la vista habitual hasta resolver el conflicto. Eso no convierte a la revisión visible en una decisión del negocio. Microsoft Field Service documenta intervalos y dependencias de sincronización; que los datos viajen con cierta frecuencia tampoco resuelve por sí solo cambios incompatibles.
Ejemplo ficticio: precio y teléfono en la versión siete
Una distribuidora tiene la ficha F-090, versión siete: precio de acuerdo 100 MXN y teléfono terminado en 0101. En oficina, ventas cambia el precio a 110 y crea versión ocho. Sin conexión, otra persona cambia ese mismo precio a 105 y el teléfono a 0202, usando todavía la versión siete. Son datos sintéticos para probar decisiones, no una regla comercial de Nightly.
Al reconectar, el precio queda en conflicto: 105 no sustituye silenciosamente a 110. El teléfono puede proponerse como cambio independiente si la regla acordada lo permite y no hay otra edición de ese campo. El responsable compara ambos precios y registra su decisión. Conservar la versión de origen permite explicar por qué la segunda captura no se aplicó completa.
| Tipo | Tratamiento propuesto | Pregunta del negocio |
|---|---|---|
| Nota nueva identificada | Agregar una vez, sin sustituir notas anteriores | ¿La nota puede vivir independiente? |
| Campo sin edición concurrente | Aplicar con comprobación de versión y dependencias | ¿Cambió algo que afecta su significado? |
| Precio editado en dos fuentes | Revisión por responsable, sin elección silenciosa | ¿Cuál compromiso está autorizado? |
| Dato con fuente única | Aceptar solo su fuente o tratar propuesta por separado | ¿Quién puede decidir ese dato? |
Haz visible lo guardado, lo enviado y lo resuelto
El usuario necesita distinguir su captura local de lo que el servidor aceptó. Muestra el motivo del conflicto y una referencia que permita retomar el trabajo; no presentes un mensaje genérico de éxito cuando parte de la edición quedó pendiente. Si la resolución requiere otra persona, conserva ambos valores y asigna el caso.
| Caso | Resultado esperado | Evidencia |
|---|---|---|
| F-090 envía precio 105 desde versión siete | Precio en revisión frente a 110 de versión ocho | Ambas versiones y conflicto |
| Teléfono 0202 sin otra edición | Aplicación independiente solo si la regla lo permite | Campo y decisión de combinación |
| Resolver precio con autorización | Una nueva versión con decisión y responsable | Historial y valor final |
| Reenviar la misma edición local | Sin nota ni modificación duplicadas | Clave de cambio e intentos |
| Resolver con una versión ya superada | Nueva revisión; no sobrescribir cambios posteriores | Versiones comparadas |
| No hay conexión después de guardar | Captura local visible como pendiente | Estado local y hora |
Un reintento no debe borrar el conflicto
Si se pierde la respuesta después de aplicar un cambio, usa su identificador para consultar el resultado antes de crear otro. Si el conflicto sigue abierto, repetir el envío no debe convertirlo en aceptado. Y si cambió el permiso del usuario mientras estaba sin conexión, decide qué capturas pueden aceptarse al volver: haberlas guardado localmente no demuestra autorización actual.
Las opciones dependen del producto, de su modelo de versiones y de qué datos se permiten fuera de línea. La hora del dispositivo puede ser incorrecta; no la uses como único criterio de prioridad. Un entorno que se reinicia puede perder datos locales según su diseño. Ensaya recuperación y exportación autorizada de pendientes antes de pedir que el usuario borre o reinstale la aplicación.
Conecta la regla con el trabajo que depende del dato
Un precio en revisión puede impedir una cotización; una dirección pendiente puede impedir despachar. Define esa consecuencia y el dueño que puede desbloquearla. Para archivos de una visita consulta evidencia de servicio sin conexión; para recepción de avisos, webhooks y reintentos, y para explicar decisiones, la bitácora.
Adapta la hoja a un dato que realmente cambie en dos lugares. Lleva sus versiones, responsables y una excepción anonimizada a una consulta gratuita de automatización de procesos. Podemos revisar si tu sistema actual ofrece una regla suficiente o qué frontera falta comprobar.
Preguntas frecuentes
Solo si el negocio acepta esa regla para el campo y puedes definir qué significa último. Hora local, recepción y versión son referencias distintas. Para precios o compromisos puede ser necesario conservar ambas propuestas y pedir una decisión.
A veces, pero comprueba sus dependencias. Cambiar una dirección y una fecha de entrega por separado puede producir una combinación que nadie autorizó. La regla debe decidir qué campos son independientes y cuáles se revisan como un conjunto.
Define qué autorización se comprobará al sincronizar y cómo se conservará una captura rechazada para revisión. Guardar fuera de línea no garantiza permiso para aplicar después. El comportamiento depende del sistema y necesita una prueba específica.
No. Es una guía de ensayo con datos ficticios. Debes comprobar almacenamiento local, reinicio, envío y resolución en los dispositivos y versiones reales. Completar resultados esperados no equivale a ejecutar la prueba.
Fuentes
- Configure offline data synchronizationMicrosoft
- Replication and conflict modelApache CouchDB
Última actualización: