Sync Engine: conceptos clave, tipos y mecanismos de trabajo

¿Qué es un motor de sincronización?

Sync Engine — es una capa arquitectónica entre la base de datos local y una API remota que gestiona el flujo de datos en ambos sentidos. Sus tareas: rastrear cambios, enviarlos al servidor, recibir cambios del servidor y resolver conflictos. El usuario interactúa con los datos locales, mientras que Sync Engine los sincroniza sin problemas con el servidor.

Sync Engine puede ser integrado (Firebase Firestore, Couchbase Lite, Realm) o personalizado — escrito para una lógica de negocio específica. Los motores integrados ofrecen funcionalidad offline-first y resolución de conflictos lista para usar. Los personalizados brindan control total sobre el formato de datos, el protocolo de sincronización y la política de conflictos.

Según Sravana Karthik (2024), autor de «Mobile Sync Engine Design Patterns», un Sync Engine personalizado está justificado para aplicaciones con lógica de negocio compleja (finanzas, salud, IoT) donde las reglas de fusión personalizadas son críticas. Para escenarios típicos (notas, chats, feeds), es suficiente un Firestore o Realm integrado.

interface SyncEngine {
    suspend fun pull(lastSyncTimestamp: Long): SyncResult
    suspend fun push(operations: List<QueuedOperation>): PushResult
    suspend fun resolve(conflicts: List<Conflict>): ResolutionResult
    fun observeSyncState(): Flow<SyncState>
}

Esta interfaz describe el contrato mínimo de Sync Engine: pull (cargar cambios del servidor), push (enviar cambios locales), resolve (manejar conflictos) y observe (monitorear el estado de sincronización). Esta abstracción permite cambiar la implementación sin modificar la capa de presentación.

Tipos de sincronización: completa, incremental y push

Sincronización completa (full sync) — cada sesión carga el conjunto completo de datos del servidor. Simple de implementar, pero inaceptable para grandes volúmenes: descargar 10,000 registros cada vez que se abre la aplicación consume tráfico y batería. La sincronización completa está justificada para datos de referencia (lista de países) con actualizaciones poco frecuentes.

Sincronización incremental — solo se transfieren los registros modificados desde la última sincronización. El servidor almacena la marca de tiempo del último cambio para cada registro o para todo el conjunto. El cliente envía lastSyncTimestamp y recibe solo los registros con updated_at > ese valor. Según Instagram Engineering (2024), la sincronización incremental reduce el volumen de datos transferidos en un 97% en comparación con la sincronización completa.

Sincronización push (iniciada por el servidor) — el propio servidor notifica al cliente la necesidad de sincronizar a través de FCM (Firebase Cloud Messaging), WebSocket o SSE (Server-Sent Events). El cliente no gasta recursos en sondeos periódicos. La sincronización push es la opción óptima para aplicaciones en tiempo real: chats, notificaciones, likes. Google Firebase Firestore utiliza WebSocket para sincronización en tiempo real con retroceso automático a HTTP polling.

Enfoque híbrido — una combinación de tipos: sincronización completa para datos base al inicio de la aplicación, luego sincronización incremental para actualizaciones y, para eventos críticos, sincronización push mediante FCM. Esto proporciona tanto velocidad como ahorro de recursos.

Sincronización incremental — cómo funcionan los puntos de control y deltas

Punto de control (checkpoint) — un valor que el cliente almacena entre sesiones de sincronización. Generalmente es el updated_at del último registro sincronizado con éxito. En la siguiente sincronización, el cliente envía el punto de control al servidor, y el servidor devuelve todos los registros con updated_at posterior al punto de control. Paginación basada en cursor — una versión avanzada donde el servidor devuelve un cursor (puntero a la siguiente página) junto con los datos.

Sincronización delta — el servidor calcula la diferencia entre el estado actual de los datos y la instantánea que el cliente vio por última vez. En lugar de enviar todos los registros, solo se transfieren las operaciones (insert, update, delete). Esto es especialmente efectivo para grandes conjuntos de datos donde solo unos pocos registros han cambiado. API de Google Drive (2025) utiliza changes.list con pageToken para la sincronización delta de archivos.

Estrategia de «deltas diferidos» — en el cliente móvil, los cambios no se envían inmediatamente sino que se almacenan en búfer en la Cola Offline. Cuando se alcanza el umbral (10 operaciones o 30 segundos), se forma un paquete delta y se envía al servidor. Según Dropbox Mobile Engineering (2024), el procesamiento por lotes de deltas redujo el número de solicitudes HTTP en un 65% y disminuyó el consumo de batería en un 12%.

data class SyncCheckpoint(
    val lastUpdated: Long,
    val pageToken: String?,
    val version: Int
)

suspend fun syncIncremental(checkpoint: SyncCheckpoint): SyncResult =
    api.pullChanges(
        since = checkpoint.lastUpdated,
        token = checkpoint.pageToken
    )

SyncCheckpoint almacena tanto la marca de tiempo como el cursor de paginación para listas largas. Punto de control de dos parámetros garantiza que ningún registro se omita o duplique al sincronizar grandes conjuntos de datos.

Sincronización push — sincronización instantánea mediante WebSocket y FCM

WebSocket — una conexión bidireccional persistente entre el cliente y el servidor. El servidor envía actualizaciones inmediatamente cuando los datos cambian. WebSocket es óptimo para aplicaciones en tiempo real: chats, streaming, trabajo colaborativo. Inconveniente: consumo de batería y tráfico para mantener la conexión (heartbeat). OkHttp WebSocket en Android y URLSessionWebSocketTask en iOS — implementaciones integradas.

Firebase Cloud Messaging (FCM) — notificaciones push que el servidor envía no para mostrarlas al usuario sino para activar la sincronización. Al recibir un silent push (mensaje de datos), la aplicación se activa e inicia el Sync Engine. FCM no requiere una conexión permanente y es más económico que WebSocket para notificaciones poco frecuentes.

SSE (Server-Sent Events) — un canal unidireccional a través del cual el servidor envía eventos al cliente. Más simple que WebSocket de implementar, pero no admite comunicación bidireccional. EventSource API (JavaScript) y OkHttp SSE (Android) — bibliotecas populares. SSE es adecuado para notificaciones sobre nuevos datos cuando el cliente no necesita enviar datos de vuelta por el mismo canal.

Según WhatsApp Engineering (2024), su Sync Engine utiliza una combinación de WebSocket para sesiones activas y FCM para activar la aplicación en segundo plano: WebSocket se desconecta después de 5 minutos de inactividad, y las actualizaciones posteriores se entregan mediante silent push.

Sincronización por instantáneas y versionado de datos

Sincronización basada en instantáneas (snapshot) — el servidor crea periódicamente una instantánea completa de los datos y le asigna una versión. El cliente almacena el número de versión actual. Si está desactualizado, descarga una nueva instantánea. Esta es una estrategia simple y confiable, pero ineficiente para cambios frecuentes — cada vez se descarga el conjunto completo de datos.

Versionado por registro — cada registro tiene un campo version. Durante la sincronización, el cliente envía las versiones de todos los registros, y el servidor devuelve solo aquellos cuya versión ha cambiado. Esto es más eficiente que la sincronización por instantáneas, pero requiere almacenar versiones en el cliente. Relojes vectoriales (Vector Clocks) — una técnica avanzada para sistemas distribuidos donde cada nodo asigna su propia versión y los conflictos se resuelven por orden parcial.

Instantánea con diff incremental — un enfoque híbrido: instantáneas completas poco frecuentes (una vez al día) + sincronización incremental entre ellas. Al iniciar después de una larga ausencia, el cliente carga una instantánea, y durante sincronizaciones frecuentes — solo deltas. Enfoque tipo Git — cada commit de datos tiene un hash, y el cliente sabe desde qué commit partir. Esto está implementado en Couchbase Lite Sync Gateway (2024) y es el estándar de referencia en confiabilidad.

data class VersionedEntryT(
    val id: String,
    val data: T,
    val version: Long,
    val deleted: Boolean
)

fun SyncEngine.resolveVersion(local: VersionedEntry*, remote: VersionedEntry*): VersionedEntry* =
    when {
        local.version > remote.version -> local
        remote.version > local.version -> remote
        else -> resolveConflict(local, remote)
    }

Regla de resolución de versiones: si las versiones coinciden — no hay cambios. Si la versión local es más reciente — gana la local. Si la versión del servidor es más reciente — gana la del servidor. Solo cuando las versiones son iguales pero los datos difieren — se llama al resolvedor de conflictos. Last Write Wins con un indicador de versión — la estrategia más simple pero confiable.

Cómo construir un Sync Engine para una aplicación móvil

Paso 1: Definir el modelo de datos — qué entidades se sincronizan, con qué frecuencia cambian y su volumen. Para cada entidad, definir la estrategia (incremental / completa / push) y el tiempo de retardo de sincronización aceptable.

Paso 2: Elegir un protocolo — REST con puntos de control, GraphQL con Subscriptions o gRPC con flujo bidireccional. GraphQL Subscriptions — una opción popular para aplicaciones modernas: un solo protocolo tanto para pull como para push. Apollo Client (2025) admite sincronización sin conexión a través de la caché del dispositivo.

Paso 3: Implementar una Cola Offline — almacenamiento local de cambios con claves de idempotencia (consulte el artículo «Offline Queue»). La cola es la base de un Sync Engine confiable: sin ella, la sincronización no garantiza la entrega de cambios.

Paso 4: Elegir un resolvedor de conflictos — LWW para casos simples, CRDT para edición colaborativa, fusión personalizada para lógica de negocio. Regla: el resolvedor debe ser idempotente — reaplicar la misma operación debe producir el mismo resultado.

Paso 5: Monitoreo y métricas — registrar cada sincronización: cantidad de registros, tiempo de ejecución, cantidad de conflictos, errores. Firebase Crashlytics o Sentry (2025) permiten rastrear errores de sincronización en tiempo real.

Según Realm Team (2024), un Sync Engine típico para aplicaciones móviles procesa 100–500 sincronizaciones por día por dispositivo, transfiriendo un promedio de 50–200 KB de datos por sesión. Optimización del protocolo — usar compresión Protobuf en lugar de JSON — reduce el volumen de datos transferidos en otro 40–60%.