Last Write Wins: ano ito, mekanismo at prinsipyo ng paggana

Ano ang Last Write Wins sa mobile development?

Last Write Wins (LWW) — ay ang diskarte ng huling pagsulat sa paglutas ng mga conflict sa synchronisation. Kapag binago ng dalawang client ang parehong object ng data, tinatanggap ng server ang parehong bersyon at pinipili ang may mas malaking timestamp. Ang LWW ay default na diskarte sa maraming distributed system: Firebase Realtime Database, Apache Cassandra, Riak KV, at DynamoDB sa mode ng huling pagsulat.

Sa mga mobile application, kaakit-akit ang LWW dahil sa tatlong dahilan: pagiging simple ng implementasyon, minimal na latency, at walang interaksyon ng user. Hindi kailangan ng developer na sumulat ng komplikadong merge logic, at hindi nakakakita ang user ng mga dialog ng pagpili ng bersyon. Ngunit ang halaga ng pagiging simple ay potensyal na pagkawala ng data, na hindi kayang bayaran ng lahat ng application.

Ayon sa pananaliksik ni Martin Kleppmann (may-akda ng „Designing Data-Intensive Applications”, O’Reilly, 2024), ang LWW ay pinakalaganap na diskarte sa production systems, ginagamit sa humigit-kumulang 70% ng distributed applications kung saan katanggap-tanggap ang eventual consistency. Sa 23% ng mga kaso, ito ay humahantong sa nasusukat na pagkawala ng data ng user.

Paano gumagana ang mekanismo ng LWW

Ang mekanismo ng LWW ay batay sa paghahambing ng mga timestamp. Ang bawat tala ng data ay may kasamang timestamp na maaaring itakda ng client (client-side timestamp) o server (server-side timestamp). Kapag may nakitang conflict, inihahambing ng system ang timestamp ng parehong bersyon at tinatanggap ang tala na may mas malaking halaga. Ang ikalawang bersyon ay itatapon o itatago sa kasaysayan para sa audit.

Ang client-side timestamp ay may kahinaan: ang mga orasan sa mga device ng user ay maaaring hindi naka-synchronize. Kung ang telepono ng user A ay 5 minuto ang atraso at ang user B ay gumawa ng mga pagbabago, ang tala ni A ay maaaring maling ituring na mas bago pagkatapos itama ang orasan. Kaya naman ang production systems ay mas madalas gumagamit ng server-side timestamp, na itinatakda ng server kapag natanggap ang data.

Lohika ng LWW na may server-side timestamp:

data class SyncDocument(
    val id: String,
    val data: String,
    val serverTimestamp: Long
)

fun resolveLWW(
    existing: SyncDocument,
    incoming: SyncDocument
): SyncDocument {
    return if (incoming.serverTimestamp >= existing.serverTimestamp)
        incoming
    else
        existing
}

Ang function na resolveLWW ay tumatanggap ng dalawang dokumento at ibinabalik ang may mas malaking timestamp. Sa pagkakapantay-pantay, karaniwang nananalo ang papasok na dokumento — ginagarantiya nito na hindi mawawala ang bagong data dahil sa pagtutugma ng mga timestamp.

Mga kalamangan at kahinaan ng Last Write Wins

Ang pangunahing kalamangan ng LWW ay algorithmic simplicity. Hindi nangangailangan ang diskarte ng pag-iimbak ng kasaysayan ng bersyon, pagsusuri ng mga pagbabago sa antas ng field, o paglutas ng mga komplikadong conflict. Pinoproseso ng server ang conflict sa isang operasyon ng paghahambing, na ginagawang pinakamabilis na diskarte ang LWW. Sa Firebase Realtime Database, pinoproseso ng LWW hanggang 100 libong conflict bawat segundo sa isang node.

Ang pangunahing kahinaan — pagkawala ng data sa mga independiyenteng pagbabago ng magkaibang field. Kung binago ng user A ang pangalan ng gawain at binago ng user B ang deskripsyon, itatapon ng LWW ang isa sa mga bersyon nang buo, kahit na dapat parehong mapanatili ang mga pagbabago. Ito ay lalong kritikal para sa mga form, profile, at configuration kung saan mahalaga ang bawat field.

Paghahambing ng LWW sa mga alternatibong diskarte:

Mga halimbawa ng implementasyon ng LWW sa Kotlin

Tingnan natin ang implementasyon ng LWW sa konteksto ng isang mobile application para sa listahan ng pamilihan kung saang maraming miyembro ng pamilya ang maaaring magdagdag at magmarka ng mga produkto offline. Ang bawat elemento ng listahan ay nag-iimbak ng ID, pangalan, status, at timestamp ng huling pag-update. Sa pag-synchronize, inilalapat ang LWW sa bawat elemento.

Pangunahing modelo ng elemento ng listahan:

data class ShoppingItem(
    val id: String,
    val name: String,
    val isChecked: Boolean,
    val quantity: Int,
    val lastModified: Long
)

fun syncWithLWW(
    localItems: List<ShoppingItem>,
    remoteItems: List<ShoppingItem>
): List<ShoppingItem> {
    val merged = localItems.toMutableList()

    remoteItems.forEach { remote ->
        val index = merged.indexOfFirst { it.id == remote.id }
        if (index == -1) {
            merged.add(remote)
        } else {
            val local = merged[index]
            merged[index] = if (remote.lastModified >= local.lastModified)
                remote
            else
                local
        }
    }
    return merged
}

Ang function na syncWithLWW ay pinagsasama ang lokal at remote na listahan: kung ang elemento ay umiiral lamang sa isang panig — idinadagdag ito, kung sa parehong panig — nananalo ang mas bagong bersyon. Ang pamamaraang ito ay nagsisiguro ng deterministikong synchronisation para sa bawat indibidwal na elemento.

LWW laban sa Merge: ano ang pipiliin

Ang pagpili sa pagitan ng LWW at Merge ay tinutukoy ng kalikasan ng pagbabago ng data. Kung pinapayagan ng application ang mga independiyenteng pagbabago ng field (iba't ibang user ang nagbabago ng magkaibang field ng parehong object), mas tumpak na mapapanatili ng Merge Strategy ang data. Kung ang mga pagbabago ay palaging atomic (binabago ng user ang buong object), ang LWW ay ganap na angkop at mas simple upang ipatupad.

Sa praktika, maraming system ang gumagamit ng hybrid approach: LWW para sa meta-impormasyon at mga field sa mataas na antas, Merge para sa structured data. Ang Firebase Firestore, halimbawa, ay gumagamit ng LWW para sa karamihan ng operasyon, ngunit sinusuportahan ang mga transaksyon na may optimistic locking para sa atomic updates kapag ang developer ay malinaw na nagsasaad na ang isang field ay hindi dapat mawala sa conflict.

Ayon sa survey ng mga developer ng distributed systems (Stack Overflow Survey, 2025), 54% ang pumipili ng LWW para sa MVP at prototypes, lumilipat sa Merge o CRDT sa yugto ng scaling. Ang pangunahing pamantayan ay dalawang conflict: kung mas mababa sa 1% ng mga session ang humahantong sa conflict, ang LWW ay higit pa sa sapat. Kung ang conflict ay nakakaapekto sa higit sa 5% ng mga session, ito ay nagkakahalaga ng pag-invest sa Merge o CRDT.