Merge Strategy — o que é, tipos de merge e princípio de funcionamento

O que é Merge Strategy no desenvolvimento mobile?

Merge Strategy é um conjunto de algoritmos que combinam versões conflitantes de dados em vez de escolher uma delas. Em aplicativos mobile, o Merge é usado quando dois clientes editam independentemente diferentes campos ou propriedades do mesmo objeto. Em vez de descartar a versão mais antiga completamente (como no LWW), o sistema analisa as diferenças no nível de campos individuais e produz um objeto resultante contendo alterações de ambas as versões.

Diferença chave entre Merge e LWW é preservar as alterações de cada usuário desde que não se contradigam. Se o usuário A alterou o nome da tarefa e o usuário B alterou a descrição, o Merge preserva ambas as alterações. Se ambos alteraram o mesmo campo — um conflito é registrado e requer resolução. Isso torna o Merge preferível para aplicativos onde os usuários trabalham colaborativamente com os mesmos dados.

De acordo com um relatório do Stripe Engineering Blog (2025), a implementação do Merge Strategy em vez do LWW reduziu o número de reclamações de usuários sobre perda de dados em 76% em seu aplicativo mobile de gerenciamento de projetos. No entanto, o tempo de processamento de conflitos aumentou em 15–30 ms, o que é considerado um preço aceitável pela integridade dos dados.

Merge triplo: como o mecanismo funciona

O merge triplo (three-way merge) é a implementação mais comum do Merge Strategy. O mecanismo opera com três versões de dados: base (estado antes da divergência), local (versão do cliente atual) e remota (versão do servidor). O sistema compara cada campo das versões local e remota com a base para determinar qual lado alterou quais campos.

A lógica de decisão é simples: se apenas um cliente alterou um campo (em relação à base), sua alteração é aceita automaticamente. Se ambos os clientes alteraram o mesmo campo — um conflito é registrado, que pode ser resolvido automaticamente (por prioridade) ou delegado ao usuário. Se nenhum cliente alterou o campo — o valor base permanece. Essa abordagem garante que alterações independentes não sejam perdidas nem conflitem.

O algoritmo de merge triplo no nível de dicionário de campos:

fun threeWayMerge(
    base: Map<String, Any?>,
    local: Map<String, Any?>,
    remote: Map<String, Any?>
): Map<String, Any?> {
    val result = base.toMutableMap()
    val allKeys = base.keys + local.keys + remote.keys

    allKeys.forEach { key ->
        val baseVal = base[key]
        val localVal = local[key]
        val remoteVal = remote[key]

        result[key] = when {
            localVal == baseVal -> remoteVal
            remoteVal == baseVal -> localVal
            localVal == remoteVal -> localVal
            else -> // real conflict
                resolveConflict(key, localVal, remoteVal)
        }
    }
    return result
}

A função threeWayMerge processa sequencialmente todas as chaves das três versões. Se o valor local corresponde à base — a alteração remota é aceita. Se o remoto corresponde à base — a alteração local é aceita. Se ambos diferem da base mas são iguais entre si — qualquer um é aceito. Um conflito real é registrado apenas quando ambos os lados têm alterações diferentes.

Resolução automática e manual de conflitos

A resolução automática é aplicada quando as alterações não se sobrepõem ou quando o sistema pode determinar o valor correto com base em regras. Por exemplo, para campos numéricos pode-se selecionar o valor máximo, para campos de texto — concatenação ou a versão mais recente. O CouchDB usa merge automático para campos de documentos JSON, e para arrays — concatenação com remoção de duplicatas.

A resolução manual é necessária quando dois usuários alteraram o mesmo campo de forma diferente. Nesse caso, o aplicativo mostra um diálogo com três opções: “aceitar versão local”, “aceitar versão remota” ou “mesclar manualmente”. De acordo com uma pesquisa da CMU (Carnegie Mellon University, 2024), a resolução manual reduz a satisfação do usuário em 40%, portanto o merge automático deve ser maximizado.

Estratégias de resolução para diferentes tipos de campos:

Exemplos de implementação de merge em Kotlin

Vamos considerar a implementação do Merge Strategy para um perfil de usuário em um aplicativo mobile com sincronização via REST API. O perfil contém nome, email, avatar e configurações de notificação. Cada campo pode ser alterado independentemente em diferentes dispositivos do usuário.

Classe de dados do perfil com versionamento no nível de campos:

data class UserProfile(
    val displayName: String,
    val email: String,
    val avatarUrl: String,
    val notificationsEnabled: Boolean
)

data class ProfileSnapshot(
    val profile: UserProfile,
    val version: Int
)

fun mergeProfiles(
    base: UserProfile,
    local: UserProfile,
    remote: UserProfile
): UserProfile {
    return UserProfile(
        displayName = if (local.displayName != base.displayName)
            local.displayName else remote.displayName,
        email = if (local.email != base.email)
            local.email else remote.email,
        avatarUrl = if (remote.avatarUrl != base.avatarUrl)
            remote.avatarUrl else local.avatarUrl,
        notificationsEnabled = if (local.notificationsEnabled != base.notificationsEnabled)
            local.notificationsEnabled
        else remote.notificationsEnabled
    )
}

A função mergeProfiles processa independentemente cada campo do perfil, selecionando a versão que difere da base. Em caso de conflito (ambas diferem da base), a prioridade é determinada pelas regras do aplicativo. No exemplo, para avatarUrl a prioridade é dada à versão remota, para os campos restantes — à local.

Merge Strategy em bancos de dados de aplicativos mobile

CouchDB e PouchDB são os bancos de dados mais conhecidos com suporte integrado ao Merge Strategy. Durante a replicação de documentos, o CouchDB usa replicação multithread com detecção de conflitos no nível de documento. A versão base é armazenada no histórico de revisões e, em caso de conflito, o sistema preserva todos os ramos conflitantes e fornece ao aplicativo uma API para resolvê-los através do mecanismo de merge.

No Firebase Firestore, o Merge é implementado através de transações com bloqueio otimista. O desenvolvedor pode especificar que certos campos devem ser atualizados atomicamente usando FieldValue.serverTimestamp() e FieldValue.arrayUnion(). No entanto, o Firestore não suporta merge triplo completo — em caso de conflito, a transação é repetida com novos dados, o que equivale a uma nova tentativa, não a um merge real.

Para aplicativos mobile em Kotlin Multiplatform e React Native, o Merge Strategy é implementado no lado do cliente. O banco de dados local (SQLite, Realm) armazena a versão de cada documento e, durante a sincronização, o cliente carrega a versão do servidor e realiza o merge localmente antes de enviar o resultado. Essa abordagem garante a integridade dos dados mesmo durante operação offline prolongada, quando mais conflitos se acumulam.