Sync Engine: conceitos-chave, tipos e mecanismos de funcionamento

O que é um mecanismo de sincronização?

Sync Engine — é uma camada arquitetônica entre o banco de dados local e uma API remota que gerencia o fluxo de dados em ambas as direções. Suas tarefas: rastrear alterações, enviá-las ao servidor, receber alterações do servidor e resolver conflitos. O usuário interage com os dados locais, enquanto o Sync Engine os sincroniza perfeitamente com o servidor.

O Sync Engine pode ser integrado (Firebase Firestore, Couchbase Lite, Realm) ou personalizado — escrito para uma lógica de negócio específica. Motores integrados oferecem funcionalidade offline-first e resolução de conflitos prontas para uso. Motores personalizados fornecem controle total sobre o formato de dados, protocolo de sincronização e política de conflitos.

De acordo com Sravana Karthik (2024), autor de «Mobile Sync Engine Design Patterns», um Sync Engine personalizado é justificado para aplicações com lógica de negócio complexa (finanças, saúde, IoT) onde regras de mesclagem personalizadas são críticas. Para cenários típicos (notas, chats, feeds), um Firestore ou Realm integrado é suficiente.

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 interface descreve o contrato mínimo do Sync Engine: pull (carregar alterações do servidor), push (enviar alterações locais), resolve (lidar com conflitos) e observe (monitorar o estado da sincronização). Essa abstração permite alterar a implementação sem modificar a camada de apresentação.

Tipos de sincronização: completa, incremental e push

Sincronização completa (Full sync) — cada sessão carrega o conjunto completo de dados do servidor. Simples de implementar, mas inaceitável para grandes volumes: baixar 10.000 registros toda vez que abre o aplicativo consome tráfego e bateria. A sincronização completa é justificada para dados de referência (lista de países) com atualizações raras.

Sincronização incremental — apenas os registros alterados desde a última sincronização são transferidos. O servidor armazena o timestamp da última alteração para cada registro ou para o conjunto inteiro. O cliente envia lastSyncTimestamp e recebe apenas registros com updated_at > esse valor. De acordo com Instagram Engineering (2024), a sincronização incremental reduz o volume de dados transferidos em 97% em comparação com a sincronização completa.

Sincronização push (iniciada pelo servidor) — o próprio servidor notifica o cliente sobre a necessidade de sincronizar via FCM (Firebase Cloud Messaging), WebSocket ou SSE (Server-Sent Events). O cliente não desperdiça recursos em polling periódico. A sincronização push é a escolha ideal para aplicações em tempo real: chats, notificações, curtidas. Google Firebase Firestore usa WebSocket para sincronização em tempo real com fallback automático para HTTP polling.

Abordagem híbrida — uma combinação de tipos: sincronização completa para dados de base na inicialização do aplicativo, depois sincronização incremental para atualizações e, para eventos críticos, sincronização push via FCM. Isso proporciona tanto velocidade quanto economia de recursos.

Sincronização incremental — como funcionam os checkpoints e deltas

Ponto de verificação (Checkpoint) — um valor que o cliente armazena entre sessões de sincronização. Geralmente é o updated_at do último registro sincronizado com sucesso. Na próxima sincronização, o cliente envia o checkpoint ao servidor, e o servidor retorna todos os registros com updated_at após o checkpoint. Paginação baseada em cursor — uma versão avançada onde o servidor retorna um cursor (apontador para a próxima página) junto com os dados.

Sincronização delta — o servidor calcula a diferença entre o estado atual dos dados e o snapshot que o cliente viu pela última vez. Em vez de enviar todos os registros, apenas as operações (insert, update, delete) são transferidas. Isso é especialmente eficaz para grandes conjuntos de dados onde apenas alguns registros foram alterados. API do Google Drive (2025) usa changes.list com pageToken para sincronização delta de arquivos.

Estratégia de «deltas adiados» — no cliente móvel, as alterações não são enviadas imediatamente, mas armazenadas em buffer na Fila Offline. Quando o limite é atingido (10 operações ou 30 segundos), um pacote delta é formado e enviado ao servidor. De acordo com Dropbox Mobile Engineering (2024), o processamento em lote de deltas reduziu o número de requisições HTTP em 65% e o consumo de bateria em 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 armazena tanto o timestamp quanto o cursor de paginação para listas longas. Checkpoint de dois parâmetros garante que nenhum registro seja pulado ou duplicado ao sincronizar grandes conjuntos de dados.

Sincronização push — sincronização instantânea via WebSocket e FCM

WebSocket — uma conexão bidirecional persistente entre o cliente e o servidor. O servidor envia atualizações imediatamente quando os dados mudam. WebSocket é ideal para aplicações em tempo real: chats, streaming, trabalho colaborativo. Desvantagem: consumo de bateria e tráfego para manter a conexão (heartbeat). OkHttp WebSocket no Android e URLSessionWebSocketTask no iOS — implementações integradas.

Firebase Cloud Messaging (FCM) — notificações push que o servidor envia não para exibir ao usuário, mas para acionar a sincronização. Ao receber um silent push (mensagem de dados), o aplicativo acorda e inicia o Sync Engine. O FCM não requer uma conexão permanente e é mais econômico que o WebSocket para notificações raras.

SSE (Server-Sent Events) — um canal unidirecional através do qual o servidor envia eventos ao cliente. Mais simples que o WebSocket de implementar, mas não suporta comunicação bidirecional. EventSource API (JavaScript) e OkHttp SSE (Android) — bibliotecas populares. SSE é adequado para notificações sobre novos dados quando o cliente não precisa enviar dados de volta pelo mesmo canal.

De acordo com WhatsApp Engineering (2024), o Sync Engine deles usa uma combinação de WebSocket para sessão ativa e FCM para ativar o aplicativo em segundo plano: o WebSocket desconecta após 5 minutos de inatividade, e as atualizações subsequentes são entregues via silent push.

Sincronização por snapshots e versionamento de dados

Sincronização baseada em snapshots — o servidor cria periodicamente um snapshot completo dos dados e atribui uma versão. O cliente armazena o número da versão atual. Se estiver desatualizado — baixa um novo snapshot. Esta é uma estratégia simples e confiável, mas ineficiente para alterações frequentes — cada vez o conjunto completo de dados é baixado.

Versionamento por registro — cada registro tem um campo version. Durante a sincronização, o cliente envia as versões de todos os registros, e o servidor retorna apenas aqueles cuja versão mudou. Isso é mais eficiente que a sincronização por snapshots, mas requer armazenamento de versões no cliente. Relógios vetoriais (Vector Clocks) — uma técnica avançada para sistemas distribuídos onde cada nó atribui sua própria versão e os conflitos são resolvidos por ordem parcial.

Snapshot com diff incremental — uma abordagem híbrida: snapshots completos raros (uma vez por dia) + sincronização incremental entre eles. Ao iniciar após uma longa ausência, o cliente carrega um snapshot e, durante sincronizações frequentes — apenas deltas. Abordagem semelhante ao Git — cada commit de dados tem um hash, e o cliente sabe de qual commit partir. Isso é implementado no Couchbase Lite Sync Gateway (2024) e é o padrão de referência em confiabilidade.

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)
    }

Regra de resolução de versão: se as versões coincidem — não há alterações. Se a versão local é mais nova — a local vence. Se a versão do servidor é mais nova — o servidor vence. Apenas quando as versões são iguais mas os dados diferem — o resolvedor de conflitos é chamado. Last Write Wins com um sinalizador de versão — a estratégia mais simples mas confiável.

Como construir um Sync Engine para uma aplicação móvel

Passo 1: Definir o modelo de dados — quais entidades são sincronizadas, com que frequência mudam e seu volume. Para cada entidade, definir a estratégia (incremental / completa / push) e o atraso de sincronização aceitável.

Passo 2: Escolher um protocolo — REST com checkpoints, GraphQL com Subscriptions ou gRPC com stream bidirecional. GraphQL Subscriptions — uma escolha popular para aplicações modernas: um protocolo tanto para pull quanto para push. Apollo Client (2025) suporta sincronização offline via cache do dispositivo.

Passo 3: Implementar uma Fila Offline — armazenamento local de alterações com chaves de idempotência (veja o artigo «Offline Queue»). A fila é a base de um Sync Engine confiável: sem ela, a sincronização não garante a entrega de alterações.

Passo 4: Escolher um resolvedor de conflitos — LWW para casos simples, CRDT para edição colaborativa, mesclagem personalizada para lógica de negócio. Regra: o resolvedor deve ser idempotente — reaplicar a mesma operação deve produzir o mesmo resultado.

Passo 5: Monitoramento e métricas — registrar cada sincronização: número de registros, tempo de execução, número de conflitos, erros. Firebase Crashlytics ou Sentry (2025) permitem rastrear erros de sincronização em tempo real.

De acordo com Realm Team (2024), um Sync Engine típico para aplicações móveis processa 100–500 sincronizações por dia por dispositivo, transferindo em média 50–200 KB de dados por sessão. Otimização de protocolo — usar compressão Protobuf em vez de JSON — reduz o volume de dados transferidos em mais 40–60%.