Synchronization

Intercambiar cambios conservando una relación definida

Synchronization es el proceso de intercambiar, comparar y reconciliar estado o cambios entre copias o representaciones para que reciban las actualizaciones requeridas por la política de consistencia de la aplicación. Es una definición de trabajo del Atlas, no una formulación normativa universal. kind: concept conserva el alcance amplio de un proceso con mecanismos muy diferentes.

La primera pregunta es qué se sincroniza: entidad, documento, preferencias, operaciones pendientes o un subconjunto de datos. «Sincronizar la app» no identifica alcance, responsables ni criterio de éxito. También debe explicarse qué relación se busca: copia informativa vigente, cambios aceptados por un owner, integración de ediciones concurrentes u otra condición comprobable.

offline-first pregunta qué utilidad continúa sin conexión inmediata. Synchronization puede ayudar a recuperar relación con el sistema, pero también existe entre clientes normalmente online. Un desktop que recibe actualizaciones incrementales puede sincronizar sin tener requisitos offline. El concepto no queda reducido a mobile, colaboración en tiempo real ni una biblioteca concreta.

Términos relacionados que no son equivalentes

Esta comparación editorial separa preguntas; las fronteras terminológicas varían entre fuentes.

Concepto cercano	Distinción relevante
Replication	Mantiene copias; sync describe intercambio y reconciliación, con posible solapamiento terminológico.
Backup	Conserva estado recuperable; propagar cambios actuales puede propagar también errores y borrados.
Cache refresh	Puede realizar actualización unidireccional; no cubre todo caso multi-writer.
Data Migration	Persigue una transición con alcance y cierre; sync puede continuar indefinidamente.
CDC	Captura cambios como mecanismo; no determina por sí solo aceptación, reconciliación o autoridad.
Realtime	Describe expectativas temporales; transporte rápido no prueba copias sincronizadas.

data-migration puede usar sincronización durante coexistencia y catch-up. Terminar un ciclo de intercambio no demuestra completar esa transición, retirar consumidores o resolver autoridad. Tampoco toda invalidación de cache constituye sync: puede señalar únicamente que la copia necesita revisión posterior.

Copias, topología y autoridad

Puede haber cliente–backend, varios dispositivos mediante un servidor, pares o combinaciones. No toda representación necesita datos completos ni toda sincronización es bidireccional. Un refresh servidor→cliente y una entrega cliente→servidor de telemetría tienen direcciones diferentes; permitir escrituras independientes en ambos lados agrega otros compromisos.

data-ownership pregunta quién valida y declara cada hecho. Un backend puede ser autoritativo para órdenes mientras un cliente gobierna un borrador local. En otro dominio varias réplicas pueden aceptar ediciones válidas sin consultar previamente a una autoridad central. La topología del transporte no decide por sí sola ese modelo.

Si varios participantes pueden escribir, hay que definir cómo se relacionan sus cambios y qué ocurre cuando no se aceptan juntos. Compartir usuario no elimina concurrencia: teléfono y laptop pueden trabajar sobre versiones diferentes. Colaboración multi-user añade otras necesidades, pero no es el caso obligatorio de todo sistema que sincroniza.

Dirección y disparo del intercambio

Pull permite que un consumidor solicite datos actuales o cambios pertinentes. Puede dispararse por navegación, acción explícita, timer o reconexión, sin intervalo universal. Push puede transportar cambios o avisar que deben buscarse; ambos significados aparecen en la literatura y no deben confundirse.

Android llama push-based synchronization al aviso de datos stale seguido de fetch. Aquí se conserva ese uso específico, sin definir todo push como notificación. Un mensaje recibido no demuestra que el contenido se haya obtenido, aplicado ni reconciliado. mobile-architecture conserva las limitaciones de push y ejecución background.

Catálogo podría refrescarse por pull y datos de cuenta reaccionar a avisos del servidor. Es una combinación posible del Atlas, no una estrategia global obligatoria. Tampoco usar WebSockets o una conexión permanente demuestra conocer todos los cambios ni aplicar correctamente los recibidos.

Full, incremental y significado del progreso

Un intercambio full puede obtener o comparar un conjunto amplio; uno incremental transfiere cambios desde una referencia. El primero puede simplificar recuperación y aumentar transferencia; el segundo reduce ciertos bytes y necesita metadata y rutas para información faltante. La elección depende de volumen, frecuencia, disponibilidad de historia y requisitos, sin ganador universal.

Cursor, secuencia, versión, watermark o change token pueden representar progreso. Hay que precisar si significa recibido, persistido, aplicado o reconocido. Avanzar el cursor antes de conservar cambios podría saltarlos después de un crash; conservarlos sin registrar avance podría hacer que vuelvan a recibirse. El contrato debe explicar ambos casos.

El protocolo de replicación de CouchDB documenta checkpoints y recuperación desde progreso común. Es una realización concreta, no requisito de usar sus campos o base. Un checkpoint de catálogo tampoco implica que adjuntos, órdenes o intenciones pendientes estén al mismo nivel de progreso.

Reinicio, resultados parciales y duplicados

Red interrumpida, storage lleno, payload inválido, autorización expirada o proceso terminado pueden cortar el intercambio. Declarar dónde se retoma, qué puede repetirse y qué evidencia permanece. No toda sincronización exige una transacción global ni todo lote parcial debe deshacerse: depende de las relaciones e invariantes de los datos.

idempotency y retry ayudan cuando respuestas o acknowledgements se pierden. Si el receptor aplicó una operación pero el emisor no lo sabe, enviarla nuevamente puede duplicar efectos no idempotentes. Definir identidad de operación o tolerancia a repetición cuando corresponde, sin confundir recepción del mensaje con confirmación comercial.

Ordering necesita el alcance requerido por semántica. Aplicar v2 antes de v1 de la misma entidad puede ser relevante; registros independientes pueden admitir otros órdenes. No imponer orden total a todo el sistema. Mostrar progreso parcial, fallos y conflictos por resolver evita que un único «synced» oculte trabajo importante pendiente.

Identidad, borrados y reaparición de datos

Una creación offline puede usar identidad estable generada por cliente o una referencia temporal que después se mapea. Deben preservarse relaciones con ediciones y reintentos anteriores. Dos objetos con nombres iguales no son necesariamente la misma entidad; recibir nuevamente una creación tampoco debería duplicarla por accidente. No existe estrategia de ID universal.

El borrado también necesita propagarse. Ausencia local puede significar eliminado, nunca descargado o fuera del subconjunto. Deletion versions, tombstones o logs son mecanismos posibles. CouchDB, por ejemplo, incluye borrados en su changes feed; ese detalle ilustra información explícita, sin adoptar su protocolo como contrato del Atlas.

Si se retira demasiado pronto la evidencia del borrado, una réplica vieja puede reintroducir datos. Retención de metadata, resync o retirada de réplicas necesitan condiciones compatibles. Propagar un borrado operacional no decide por sí mismo qué historia conserva otra representación para sus obligaciones; sincronización y disposición de información son preguntas distintas.

Conflicto semántico y políticas explícitas

Conflicto no significa simplemente valores diferentes: aparece cuando cambios no pueden aplicarse conjuntamente bajo la semántica pretendida. Dos adiciones independientes pueden combinarse; dos ediciones de una descripción pueden requerir decisión. Incluso cambios en campos separados pueden violar una regla que relaciona ambos.

Server wins, client wins, last write wins, merge por campos, merge de dominio y resolución manual expresan políticas con costos distintos. Enumerarlas no recomienda ninguna por defecto. Algunas descartan información válida; otras requieren interacción o contexto que el protocolo no conoce. Registrar qué se conserva y quién decide hace visible esa elección.

Reconciliation compara representaciones y resultados para recuperar la relación pretendida. Detectar conflicto es solo una parte: puede faltar aplicar una regla, pedir intervención, incorporar un rechazo o reconstruir la vista. client-state-management conserva la diferencia entre copia optimista, borrador e información confirmada; revertir un snapshot puede pisar trabajo posterior.

LWW, relojes y control de versiones

Android presenta last write wins como enfoque común en contexto móvil, no como default del Atlas. LWW puede elegir un valor y descartar cambios concurrentes válidos. Hay que explicar qué define «last»: recepción, secuencia del servidor o timestamp de dispositivo producen resultados potencialmente diferentes.

Relojes físicos independientes pueden estar desajustados. Un timestamp mayor no demuestra por sí mismo posterioridad causal ni preferencia comercial. Versiones, revisiones o metadata causal pueden ayudar a detectar relaciones entre cambios, con costos y garantías diferentes. No se prescribe un reloj o esquema universal.

RFC 9110, If-Match, ofrece un ejemplo de precondición para evitar sobrescrituras accidentales. Un backend puede rechazar una mutación basada en representación vieja; después puede requerirse refresh, merge o decisión del usuario. Reenviar el mismo payload sobre una versión nueva sin revisar intención no constituye automáticamente una recuperación correcta.

CRDTs: convergencia bajo supuestos, no solución total

Shapiro, Preguiça, Baquero y Zawirski, Conflict-free Replicated Data Types, 2011, estudian condiciones suficientes para Strong Eventual Consistency. En modelos basados en estado, merge y evolución deben satisfacer propiedades apropiadas; en modelos basados en operaciones, importan conmutatividad de operaciones concurrentes y condiciones de entrega. No basta llamar CRDT a un objeto mutable.

La convergencia depende de los supuestos del tipo y comunicación, incluyendo entrega eventual requerida. Que las actualizaciones no necesiten coordinación remota previa no elimina propagar información. El término synchronization de esta nota abarca ese intercambio; la ausencia de sincronización por update en la formulación del paper no significa ausencia de mensajes o persistencia.

Los CRDTs son una familia posible, no sinónimo ni requisito de Synchronization u Offline First. Su merge no decide que dos matrículas sobre la última plaza sean comercialmente válidas. Local-first software los considera prometedores para colaboración multi-writer y control de datos del usuario. Ese contexto no convierte toda aplicación offline en un editor colaborativo.

Invariantes que no se resuelven mezclando campos

En University, dos dispositivos pueden ordenar preferencias de secciones. Su reconciliación requiere una política explícita sobre listas y cambios concurrentes. La adjudicación de la última plaza es otra operación: combinar preferencias no crea capacidad adicional ni sustituye la decisión autoritativa de matrícula.

Si una invariante exige coordinación con estado globalmente actual, la operación puede permanecer online-only o requerir otro protocolo específico. No se deduce una solución de un slogan CAP ni de la disponibilidad local. Convergencia de bytes y preservación de obligaciones de negocio son propiedades distintas.

En Commerce, teléfono y laptop pueden editar cart mientras Inventory cambia. Hay que declarar autoridad, identidad y semántica de combinación. Una cantidad local pendiente puede ser rechazada; sincronizar implica reflejar esa decisión, no forzar al servidor a aceptar toda intención. La confirmación de Payments conserva su propio contrato.

Recuperación que no amplifica la caída

Al recuperarse una conexión compartida, muchos clientes pueden intentar descargar y enviar trabajo simultáneamente. jitter y backpressure aportan mecanismos para distribuir intentos o limitar admisión bajo su alcance. Agregar retry en cada capa sin presupuesto puede amplificar carga, aun cuando todos intenten recuperar información legítima.

Full resync, cambios incrementales, batching y frecuencia intercambian simplicidad, bandwidth y metadata. En mobile, red y procesamiento consumen energía y presupuesto de background. No hay intervalo fijo correcto ni garantía de ejecución inmediata por programar una tarea. Evitar convertir la recuperación en una nueva fuente de saturación.

Algunos diseños buscan convergencia cuando la comunicación se restablece y los cambios pertinentes se entregan bajo una política compatible. No todo diseño de sync la garantiza: puede haber rechazos, réplicas retiradas, pérdida de información o trabajo manual pendiente. Declarar supuestos y estado observable permite evaluar la promesa real.

Evolución, autorización y evidencia

Un cliente puede reconectar después de cambios de schema, permisos o backend. interfaces, parallel-change y deprecation ayudan a conservar contratos soportados y transiciones explícitas. Validar una intención cuando se guardó no concede autorización permanente para ejecutarla. Cambiar de cuenta también requiere evitar mezclar trabajo e información entre identidades.

Migrar el schema local mediante Data Migration y luego continuar intercambio remoto son operaciones distintas. La primera puede ser requisito para interpretar payloads pendientes; la segunda mantiene relación entre representaciones. Compatibilidad no se limita a tipos: un campo con significado nuevo puede volver inválida una intención antigua aunque todavía deserialice.

operability puede observar último éxito, progreso, pendientes, rechazos, conflictos, duración y versión, sin imponer un schema de telemetría. «Último contacto» no prueba sincronización completa. El usuario puede necesitar conocer pendiente, stale o conflicto según consecuencia; un icono universal no reemplaza esa semántica.

Commerce, University y los dos alcances

Como ejemplo del Atlas, tras reconexión Commerce puede enviar una wishlist addition, consultar catálogo y órdenes, incorporar rechazos y actualizar vistas. El orden depende de contratos y dependencias. Pago requiere confirmación remota en este ejemplo; catálogo offline puede seguir siendo útil aunque sus precios necesiten nueva validación para comprar.

University permite consultar cursos descargados y editar preferencias sin adjudicar plazas localmente. Los cambios de ambos dispositivos pueden volver con divergencia y necesitar resolución, mientras matrícula conserva su invariante de capacidad. No elegir LWW solo porque existe un timestamp: primero definir qué intención y evidencia deben preservarse.

Una guía de museo sin escrituras compartidas combina utilidad offline y refresh simple. Un desktop siempre conectado puede sincronizar cache incremental sin ofrecer uso offline. frontend-and-client-architecture conecta ambos recorridos: capacidad bajo desconexión y coordinación de copias se relacionan, pero requieren decisiones propias y no siempre la misma complejidad.