Last Write Wins: apa itu, mekanisme dan prinsip kerja

Apa itu Last Write Wins dalam pengembangan seluler?

Last Write Wins (LWW) — adalah strategi penulisan terakhir dalam menyelesaikan konflik sinkronisasi. Ketika dua klien mengubah objek data yang sama, server menerima kedua versi dan memilih yang memiliki stempel waktu (timestamp) lebih besar. LWW adalah strategi default di banyak sistem terdistribusi: Firebase Realtime Database, Apache Cassandra, Riak KV, dan DynamoDB dalam mode penulisan terakhir.

Dalam aplikasi seluler, LWW menarik karena tiga alasan: kesederhanaan implementasi, latensi minimal, dan tidak ada interaksi pengguna. Pengembang tidak perlu menulis logika penggabungan yang rumit, dan pengguna tidak melihat dialog pemilihan versi. Namun, harga dari kesederhanaan adalah potensi kehilangan data, yang tidak semua aplikasi mampu tanggung.

Menurut penelitian Martin Kleppmann (penulis „Designing Data-Intensive Applications”, O’Reilly, 2024), LWW adalah strategi yang paling luas digunakan dalam sistem produksi, dipakai di sekitar 70% aplikasi terdistribusi di mana konsistensi akhir (eventual consistency) dapat diterima. Dalam 23% kasus, ini menyebabkan kehilangan data pengguna yang terukur.

Bagaimana mekanisme LWW bekerja

Mekanisme LWW didasarkan pada perbandingan stempel waktu. Setiap catatan data disertai dengan timestamp yang dapat diatur oleh klien (client-side timestamp) atau server (server-side timestamp). Saat konflik terdeteksi, sistem membandingkan timestamp kedua versi dan menerima catatan dengan nilai lebih besar. Versi kedua dibuang atau disimpan dalam riwayat untuk audit.

Client-side timestamp memiliki kekurangan: jam pada perangkat pengguna mungkin tidak sinkron. Jika ponsel pengguna A tertinggal 5 menit dan pengguna B melakukan perubahan, catatan A mungkin secara salah dianggap lebih baru setelah perbaikan jam. Oleh karena itu, sistem produksi lebih sering menggunakan server-side timestamp, yang ditetapkan oleh server saat menerima data.

Logika LWW dengan 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
}

Fungsi resolveLWW menerima dua dokumen dan mengembalikan dokumen dengan timestamp lebih besar. Jika sama, biasanya dokumen yang masuk menang — ini memastikan data baru tidak hilang karena kebetulan stempel waktu.

Kelebihan dan kekurangan Last Write Wins

Kelebihan utama LWW adalah kesederhanaan algoritmik. Strategi ini tidak memerlukan penyimpanan riwayat versi, analisis perubahan pada tingkat bidang, atau penyelesaian konflik yang kompleks. Server memproses konflik dalam satu operasi perbandingan, menjadikan LWW strategi tercepat. Di Firebase Realtime Database, LWW memproses hingga 100 ribu konflik per detik pada satu node.

Kekurangan utama — kehilangan data saat perubahan independen pada bidang yang berbeda. Jika pengguna A mengubah nama tugas dan pengguna B mengubah deskripsi, LWW akan membuang salah satu versi sepenuhnya, padahal kedua perubahan harus dipertahankan. Ini sangat kritis untuk formulir, profil, dan konfigurasi di mana setiap bidang penting.

Perbandingan LWW dengan strategi alternatif:

Contoh implementasi LWW di Kotlin

Mari kita lihat implementasi LWW dalam konteks aplikasi seluler daftar belanja di mana beberapa anggota keluarga dapat menambahkan dan menandai produk secara offline. Setiap elemen daftar menyimpan ID, nama, status, dan stempel waktu pembaruan terakhir. Saat sinkronisasi, LWW diterapkan untuk setiap elemen.

Model dasar elemen daftar:

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
}

Fungsi syncWithLWW menggabungkan daftar lokal dan jarak jauh: jika elemen hanya ada di satu sisi — ditambahkan, jika di kedua sisi — versi yang lebih baru menang. Pendekatan ini memastikan sinkronisasi deterministik untuk setiap elemen individual.

LWW vs Merge: apa yang harus dipilih

Pilihan antara LWW dan Merge ditentukan oleh sifat modifikasi data. Jika aplikasi memungkinkan perubahan independen pada bidang (pengguna berbeda mengubah bidang berbeda dari objek yang sama), Merge Strategy akan menyimpan data dengan lebih akurat. Jika perubahan selalu atomik (pengguna mengubah seluruh objek), LWW sepenuhnya memadai dan jauh lebih sederhana untuk diimplementasikan.

Dalam praktiknya, banyak sistem menerapkan pendekatan hibrida: LWW untuk meta-informasi dan bidang tingkat atas, Merge untuk data terstruktur. Firebase Firestore, misalnya, menggunakan LWW untuk sebagian besar operasi, tetapi mendukung transaksi dengan penguncian optimis untuk pembaruan atomik ketika pengembang secara eksplisit menentukan bahwa bidang tidak boleh hilang saat konflik.

Menurut survei pengembang sistem terdistribusi (Stack Overflow Survey, 2025), 54% memilih LWW untuk MVP dan purwarupa, beralih ke Merge atau CRDT pada tahap penskalaan. Kriteria kuncinya adalah frekuensi konflik: jika kurang dari 1% sesi menghasilkan konflik, LWW sudah lebih dari cukup. Jika konflik mempengaruhi lebih dari 5% sesi, ada baiknya berinvestasi dalam Merge atau CRDT.