Conflict Resolution: mga estratehiya, pagsasanib at prinsipyo ng paggana

Ano ang paglutas ng salpukan sa mga mobile application?

Paglutas ng salpukan ay ang proseso ng pagdadala ng distributed data sa iisang consistent na estado pagkatapos matukoy ang magkakasalungat na pagbabago. Sa mga sentralisadong sistema, hindi nangyayari ang mga salpukan: sunod-sunod na pinoproseso ng server ang mga kahilingan. Sa mga mobile application na may offline mode, binabago ng client ang data nang lokal at nag-sync sa server mamaya. Kung binago ng dalawang client ang iisang object, makakatanggap ang server ng dalawang bersyon na may parehong identifier ngunit magkaibang nilalaman.

Hindi maiiwasan ang mga salpukan sa loosely coupled replication (eventual consistency), kapag isinakripisyo ng system ang agarang consistency para sa availability at performance. Ayon sa mga mananaliksik mula sa Princeton University (Aggarwal et al., GEO paper, KDD 2024), ang mga system na may delayed replication ay nagpapakita ng 28% na mas mataas na performance sa peak loads, ngunit nangangailangan ng mga mekanismo ng paglutas ng salpukan para sa tamang operasyon.

Ang estratehiya ng paglutas ay isang algorithm na awtomatikong inilalapat ng system kapag may natukoy na salpukan. Iba't ibang database at framework ang nagpapatupad ng iba't ibang estratehiya: Ginagamit ng Firebase Realtime Database ang LWW, nagdadagdag ang CouchDB ng suporta sa Merge, at ang Figma at Notion ay nagtatayo ng arkitektura sa CRDT.

Bakit nagkakaroon ng mga salpukan sa synchronisasyon ng data

Ang pangunahing sanhi ng mga salpukan ay ang sabay-sabay na pagbabago ng iisang resource ng dalawa o higit pang client na nagtatrabaho sa lokal na kopya ng data. Karaniwang senaryo: nag-eedit si user A ng isang gawain sa Trello offline, sabay na binabago ni user B ang paglalarawan ng parehong gawain sa ibang device. Pareho nilang sine-save ang kanilang mga bersyon nang lokal. Kapag kumonekta ang mga device sa network, nakatanggap ang server ng dalawang magkaibang halaga para sa iisang field.

Ang mga karagdagang salik ay network delays at network partition. Sa mga distributed database na gumagamit ng Raft o Paxos protocol, maaaring magkaroon ng salpukan kapag ang lider ng cluster ay pansamantalang hindi available at ang mga kahilingan ay pinoproseso ng iba't ibang node. Ayon sa Amazon DynamoDB whitepaper (2025), humigit-kumulang 0.3% ng lahat ng write operation sa scalable NoSQL system ay humahantong sa mga nakikitang salpukan.

Nagkakaroon din ng mga salpukan dahil sa hindi tamang istruktura ng data. Kung ang application ay nag-iimbak ng counter ng operasyon o listahan ng mga kalahok, dalawang offline client ay maaaring magsagawa ng mga operasyon na sunod-sunod na hindi tugma. Halimbawa, nagdagdag si client A ng elemento sa dulo ng listahan, habang tinanggal ni client B ang isang elemento mula sa gitna — sa synchronisasyon ay hindi alam ng server kung aling aksyon ang unang ilalapat.

Last Write Wins — estratehiya ng panalo ayon sa oras

Last Write Wins (LWW) — estratehiya kung saan mula sa naglalabanang bersyon ay pipiliin ang tala na may pinakahuling timestamp. Inihahambing ng system ang timestamp ng bawat bersyon at tinatanggap ang mas bago, itinatapon ang luma. Ito ay isang deterministic na mekanismo: sa parehong set ng mga timestamp, ang resulta ay palaging pareho, na nag-aalis ng kawalan ng katiyakan. Ang LWW ay ipinatupad sa Firebase Realtime Database, Apache Cassandra, at Riak KV.

Sa mga mobile application, ang LWW ay lalong kaakit-akit dahil sa kasimplehan ng implementasyon. Hindi kailangang suriin ng client ang pagkakaiba sa pagitan ng mga bersyon, mag-imbak ng kasaysayan ng mga pagbabago, o magpakita sa user ng dialog ng pagpili. Ang server ay gumagawa ng desisyon sa millisecond. Gayunpaman, ang LWW ay may pangunahing kakulangan — pagkawala ng data. Kung dalawang user ang sabay na nagpupuno ng magkaibang field ng isang form, ang bersyon ng isa sa kanila ay ganap na itatapon.

Halimbawa ng paggana ng LWW sa isang mobile note app na may sync sa pamamagitan ng REST API:

data class Note(
    val id: String,
    val title: String,
    val content: String,
    val updatedAt: Long
)

fun resolveWithLWW(
    local: Note,
    remote: Note
): Note {
    return if (local.updatedAt >= remote.updatedAt) local
    else remote
}

Ang function na resolveWithLWW ay nagkukumpara ng mga timestamp at nagbabalik ng kasalukuyang bersyon. Kapag pantay ang timestamp (na nangyayari sa mataas na dalas ng pagsulat), karaniwang panalo ang lokal na bersyon.

Merge Strategy — pagsasanib ng nagkakasalungat na bersyon

Merge Strategy — paraan kung saan hindi itinatapon ng system ang isa sa mga bersyon nang buo, sa halip ay sinusubukang pagsamahin ang mga pagbabago mula sa pareho sa isang consistent na estado. Ito ay kahalintulad sa pagsasanib ng mga branch sa Git: bawat salpukan ay nilulutas sa antas ng indibidwal na field o operasyon. Ang mga Merge strategy ay nahahati sa awtomatiko (CRDT, OT) at manwal (pumipili ang user ng variant).

Ang pinakakilalang implementasyon ay three-way merge. Nag-iimbak ang system ng tatlong bersyon: lokal, remote, at ang kanilang karaniwang ninuno (base version bago mag-diverge). Kung ang isang field ay binago lamang ng isang client, ang pagbabago nito ay awtomatikong tinatanggap. Kung parehong binago ng dalawang client ang parehong field — itinatala ang isang salpukan na nangangailangan ng paglutas. Aktibong ginagamit ng CouchDB at PouchDB ang modelong ito para sa synchronisasyon ng dokumento.

Halimbawa ng implementasyon ng three-way merge para sa profile ng user:

data class Profile(
    val name: String,
    val email: String,
    val avatarUrl: String
)

fun threeWayMerge(
    base: Profile,
    local: Profile,
    remote: Profile
): Profile {
    return Profile(
        name = if (local.name != base.name) local.name
                else remote.name,
        email = if (local.email != base.email) local.email
                else remote.email,
        avatarUrl = if (remote.avatarUrl != base.avatarUrl) remote.avatarUrl
                    else local.avatarUrl
    )
}

Three-way merge ay epektibo kapag ang istruktura ng data ay sapat na stable. Lumilitaw ang mga problema kapag pinapalitan ang pangalan ng field, binabago ang mga uri, at operasyon sa mga array — sa mga kasong ito kinakailangan ang mas kumplikadong lohika.

CRDT — mga istruktura ng data na walang salpukan

CRDT (Conflict-Free Replicated Data Type) — mathematical model na ginagarantiyahan ang convergence ng data nang walang sentral na coordinator. Ang CRDT ay dinisenyo upang ang lahat ng operasyon ay commutative: ang pagkakasunud-sunod ng paglalapat ay hindi nakakaapekto sa huling resulta. Ito ay nakakamit sa pamamagitan ng algebraic properties: ang pagsasanib ng CRDT ay laging nagbibigay ng parehong resulta anuman ang pagkakasunud-sunod ng pagtanggap ng mga pagbabago.

Ang mga pangunahing uri ng CRDT ay kinabibilangan ng G-Counter (counter na sumusuporta lamang sa increment), PN-Counter (counter na may increment at decrement), LWW-Register (register na may versioning), at OR-Set (set na sumusubaybay sa pagdaragdag at pagtanggal). Ang bawat uri ay ginagarantiyahan na sa pagsasanib ng dalawang replica ay hindi magkakaroon ng mga salpukan. Ayon sa pananaliksik ng INRIA (Marc Shapiro et al., 2024), ang CRDT ay nagbibigay ng deterministic convergence para sa 95% ng mga karaniwang uri ng data.

Halimbawa ng G-Counter — isang counter na maaari lamang dagdagan:

class GCounter {
    private val counts = mutableMapOf<String, Int>()

    fun increment(nodeId: String) {
        counts[nodeId] = (counts[nodeId] ?: 0) + 1
    }

    fun value(): Int = counts.values.sum()

    fun merge(other: GCounter) {
        other.counts.forEach { (node, count) ->
            counts[node] = maxOf(counts[node] ?: 0, count)
        }
    }
}

GCounter ay ginagarantiyahan ang kawastuhan ng pagsasanib dahil ang bawat node ay nag-iimbak lamang ng sarili nitong counter, at ang merge ay kumukuha ng maximum para sa bawat node. Ito ay isang klasikong halimbawa ng istrukturang walang salpukan, na ginagamit sa mga desentralisadong sistema.

Paano pumili ng estratehiya ng paglutas ng salpukan

Pagpili ng estratehiya ay depende sa kalikasan ng data at mga senaryo ng paggamit. Ang LWW ay optimal para sa mga application kung saan ang pinakabagong bersyon ay laging may priyoridad — news feed, notification, status. Ang Merge Strategy ay angkop para sa mga structured na dokumento kung saan ang bawat field ay independyente — mga profile ng user, form, configuration. Ang CRDT ay perpekto para sa collaborative editing, listahan, at counter sa mga distributed system.

Sa pagpili ng estratehiya, tatlong salik ang tinatasa: consistency ng data, performance, at pagiging kumplikado ng implementasyon. Ang LWW ay nagbibigay ng maximum na performance at minimum na kumplikasyon, ngunit maaaring mawalan ng data. Ang Merge ay nagbibigay ng mataas na katumpakan, ngunit nangangailangan ng mekanismo ng pagtuklas ng pagbabago sa antas ng field. Ang CRDT ay ginagarantiyahan ang mathematical correctness, ngunit nagpapataw ng mga limitasyon sa mga uri ng data at laki ng metadata.

Sa praktika, madalas ginagamit ang kombinadong paraan: ginagamit ng mga system ang LWW para sa metadata, Merge para sa nilalaman ng dokumento, at CRDT para sa listahan na mga istruktura. Ang Firebase Firestore, halimbawa, ay naglalapat ng LWW para sa mga field sa pinakamataas na antas at sumusuporta sa mga transaksyon para sa atomic na pag-update. Ang CouchDB ay gumagamit ng Merge na may imbakan ng kasaysayan ng pagbabago. Ang Figma at Notion ay nagtatayo ng arkitektura batay sa CRDT para sa multi-user real-time na pag-edit.