Merge Strategy — ano ito, mga uri ng pagsasama at prinsipyo ng paggana

Ano ang Merge Strategy sa mobile development?

Merge Strategy — koleksyon ng mga algorithm na pinagsasama ang magkakasalungat na bersyon ng data sa halip na pumili ng isa sa mga ito. Sa mga mobile app, ginagamit ang Merge kapag independiyenteng ini-edit ng dalawang kliyente ang iba't ibang field o property ng parehong object. Sa halip na itapon ang mas lumang bersyon nang buo (tulad ng sa LWW), sinusuri ng system ang mga pagkakaiba sa antas ng indibidwal na field at bumubuo ng resultang object na naglalaman ng mga pagbabago mula sa parehong bersyon.

Pangunahing pagkakaiba ng Merge sa LWW — pagpapanatili ng mga pagbabago ng bawat gumagamit sa kondisyon na hindi sila magkasalungat. Kung binago ng gumagamit A ang pangalan ng gawain, at gumagamit B ang paglalarawan, pananatilihin ng Merge ang parehong pagbabago. Kung parehong binago ang parehong field — naitala ang alitan na nangangailangan ng paglutas. Ginagawa nitong mas pinipili ang Merge para sa mga app kung saan magkakasamang nagtatrabaho ang mga gumagamit sa parehong data.

Ayon sa ulat ng Stripe Engineering Blog (2025), ang pagpapatupad ng Merge Strategy sa halip na LWW ay nagbawas ng bilang ng mga reklamo ng gumagamit tungkol sa pagkawala ng data ng 76% sa kanilang mobile project management app. Gayunpaman, ang oras ng pagproseso ng alitan ay tumaas ng 15–30 ms, na itinuturing na isang katanggap-tanggap na presyo para sa pagpapanatili ng impormasyon.

Three-way merge: paano gumagana ang mekanismo

Three-way merge — ang pinakakaraniwang implementasyon ng Merge Strategy. Ang mekanismo ay nagpapatakbo sa tatlong bersyon ng data: base (base — estado bago ang divergence), lokal (local — bersyon ng kasalukuyang kliyente), at remote (remote — bersyon mula sa server). Inihahambing ng system ang bawat field ng lokal at remote na bersyon sa base upang matukoy kung aling partido ang nagbago kung aling mga field.

Ang lohika ng paggawa ng desisyon ay simple: kung ang isang field ay binago lamang ng isang kliyente (kaugnay ng base), ang pagbabago nito ay awtomatikong tinatanggap. Kung parehong binago ng parehong kliyente ang parehong field — naitala ang alitan na maaaring awtomatikong malutas (ayon sa priyoridad) o ipasa sa gumagamit. Kung walang kliyente na nagbago ng field — nananatili ang base na halaga. Ginagarantiyahan ng approach na ito na ang mga independiyenteng pagbabago ay hindi nawawala at hindi nagkakasalungatan.

Algorithm ng three-way merge sa antas ng diksyunaryo ng field:

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 -> // tunay na alitan
                resolveConflict(key, localVal, remoteVal)
        }
    }
    return result
}

Ang function na threeWayMerge ay sunod-sunod na nagpoproseso ng lahat ng key mula sa tatlong bersyon. Kung ang lokal na halaga ay tumutugma sa base — tinatanggap ang remote na pagbabago. Kung ang remote na halaga ay tumutugma sa base — tinatanggap ang lokal na pagbabago. Kung parehong naiiba sa base ngunit pantay sa isa't isa — alinman. Ang tunay na alitan ay naitala lamang kapag may magkaibang pagbabago mula sa magkabilang panig.

Awtomatiko at manwal na paglutas ng alitan

Awtomatikong paglutas ay inilalapat kapag ang mga pagbabago ay hindi nag-o-overlap o kapag matutukoy ng system ang tamang halaga batay sa mga patakaran. Halimbawa, para sa numerikong field maaaring piliin ang maximum na halaga, para sa text field — concatenation o mas bagong bersyon. Gumagamit ang CouchDB ng awtomatikong pagsasama para sa mga field ng JSON document, at para sa arrays — concatenation na may pagtanggal ng mga duplicate.

Manwal na paglutas ay kinakailangan kapag dalawang gumagamit ang nagbago ng parehong field sa magkaibang paraan. Sa kasong ito, ang app ay nagpapakita ng dialog na may tatlong opsyon: “tanggapin ang lokal na bersyon”, “tanggapin ang remote na bersyon” o “manu-manong pagsamahin”. Napansin ng mga may-akda ng pananaliksik ng CMU (Carnegie Mellon University, 2024) na ang manwal na paglutas ay nagbabawas ng kasiyahan ng gumagamit ng 40%, kaya ang awtomatikong pagsasama ay dapat na i-maximize.

Mga estratehiya ng paglutas para sa iba't ibang uri ng field:

Mga halimbawa ng implementasyon ng pagsasama sa Kotlin

Isaalang-alang natin ang implementasyon ng Merge Strategy para sa profile ng gumagamit sa isang mobile app na may sync sa pamamagitan ng REST API. Ang profile ay naglalaman ng pangalan, email, avatar, at mga setting ng notipikasyon. Ang bawat field ay maaaring baguhin nang independiyente sa iba't ibang device ng gumagamit.

Data class ng profile na may versioning sa antas ng field:

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

Ang function na mergeProfiles ay independiyenteng nagpoproseso ng bawat field ng profile, pinipili ang bersyon na naiiba sa base. Sa alitan (parehong naiiba sa base), ang priyoridad ay tinutukoy ng mga patakaran ng app. Sa halimbawa, para sa avatarUrl ang priyoridad ay ibinibigay sa remote na bersyon, para sa iba pang field — sa lokal na bersyon.

Merge Strategy sa mga database ng mobile apps

CouchDB at PouchDB — ang pinakakilalang database na may built-in na suporta para sa Merge Strategy. Sa pag-replicate ng dokumento, gumagamit ang CouchDB ng multi-thread replication na may detection ng alitan sa antas ng dokumento. Ang base na bersyon ay naka-imbak sa kasaysayan ng rebisyon, at sa alitan, pinapanatili ng system ang lahat ng magkakasalungat na sangay at nagbibigay sa app ng API para sa kanilang paglutas sa pamamagitan ng mekanismo ng pagsasama.

Sa Firebase Firestore, ang Merge ay ipinatupad sa pamamagitan ng mga transaksyon na may optimistikong pag-lock. Maaaring tukuyin ng developer na ang ilang mga field ay dapat i-update nang atomiko gamit ang FieldValue.serverTimestamp() at FieldValue.arrayUnion(). Gayunpaman, hindi sinusuportahan ng Firestore ang buong three-way merge — sa alitan, ang transaksyon ay inuulit gamit ang bagong data, na katumbas ng muling pagsubok, hindi tunay na pagsasama.

Para sa mga mobile app sa Kotlin Multiplatform at React Native, ang Merge Strategy ay ipinatupad sa panig ng kliyente. Ang lokal na database (SQLite, Realm) ay nag-iimbak ng bersyon ng bawat dokumento, at sa pag-sync, ikinakarga ng kliyente ang bersyon mula sa server at ginagawa ang pagsasama nang lokal bago ipadala ang resulta. Ginagarantiyahan ng approach na ito ang pagpapanatili ng data kahit na sa matagal na offline na trabaho kapag mas maraming alitan ang naipon.