Conflict Resolution: strategi, penggabungan dan prinsip kerja

Apa itu resolusi konflik di aplikasi seluler?

Resolusi konflik adalah proses membawa data terdistribusi ke keadaan konsisten tunggal setelah mendeteksi perubahan yang bertentangan. Dalam sistem terpusat, konflik tidak terjadi: server memproses permintaan secara berurutan. Di aplikasi seluler dengan mode offline, klien mengubah data secara lokal dan sinkronisasi dengan server nanti. Jika dua klien telah mengubah objek yang sama, server menerima dua versi dengan pengenal yang sama tetapi konten berbeda.

Konflik tidak terhindarkan dalam replikasi dengan kopling longgar (eventual consistency), ketika sistem mengorbankan konsistensi langsung demi ketersediaan dan kinerja. Menurut peneliti dari Princeton University (Aggarwal et al., GEO paper, KDD 2024), sistem dengan replikasi tertunda menunjukkan kinerja 28% lebih tinggi pada beban puncak, tetapi memerlukan mekanisme resolusi konflik untuk berfungsi dengan benar.

Strategi resolusi adalah algoritma yang diterapkan sistem secara otomatis saat mendeteksi konflik. Berbagai database dan framework mengimplementasikan strategi yang berbeda: Firebase Realtime Database menggunakan LWW, CouchDB menambahkan dukungan Merge, dan Figma serta Notion membangun arsitektur pada CRDT.

Mengapa konflik terjadi saat sinkronisasi data

Penyebab utama konflik adalah perubahan simultan pada sumber daya yang sama oleh dua atau lebih klien yang bekerja dengan salinan data lokal. Skenario tipikal: pengguna A mengedit tugas di Trello secara offline, sementara pengguna B mengubah deskripsi tugas yang sama di perangkat lain. Keduanya menyimpan versi mereka secara lokal. Saat perangkat terhubung ke jaringan, server menerima dua nilai berbeda untuk bidang yang sama.

Faktor tambahan termasuk keterlambatan jaringan dan partisi jaringan (network partition). Dalam database terdistribusi yang menggunakan protokol Raft atau Paxos, konflik dapat terjadi ketika pemimpin cluster untuk sementara tidak tersedia dan permintaan diproses oleh node yang berbeda. Menurut whitepaper Amazon DynamoDB (2025), sekitar 0,3% dari semua operasi tulis di sistem NoSQL yang dapat diskalakan menyebabkan konflik yang dapat dideteksi.

Konflik juga muncul karena struktur data yang tidak tepat. Jika aplikasi menyimpan penghitung operasi atau daftar peserta, dua klien offline dapat melakukan operasi yang tidak kompatibel secara berurutan. Misalnya, klien A menambahkan elemen ke akhir daftar, sementara klien B menghapus elemen dari tengah — saat sinkronisasi server tidak tahu tindakan mana yang harus diterapkan terlebih dahulu.

Last Write Wins — strategi pemenang berdasarkan waktu

Last Write Wins (LWW) — strategi di mana dari versi yang bersaing, catatan dengan stempel waktu terbaru dipilih. Sistem membandingkan timestamp setiap versi dan menerima yang lebih baru, membuang yang lama. Ini adalah mekanisme deterministik: dengan kumpulan stempel yang sama, hasilnya selalu sama, yang menghilangkan ketidakpastian. LWW diimplementasikan di Firebase Realtime Database, Apache Cassandra, dan Riak KV.

Di aplikasi seluler, LWW sangat menarik karena kesederhanaan implementasi. Klien tidak perlu menganalisis perbedaan antar versi, menyimpan riwayat perubahan, atau menampilkan dialog pilihan kepada pengguna. Server mengambil keputusan dalam milidetik. Namun LWW memiliki kelemahan mendasar — kehilangan data. Jika dua pengguna secara bersamaan mengisi bidang yang berbeda dari formulir yang sama, versi salah satu dari mereka akan dibuang seluruhnya.

Contoh kerja LWW di aplikasi catatan seluler dengan sinkronisasi melalui 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
}

Fungsi resolveWithLWW membandingkan stempel waktu dan mengembalikan versi saat ini. Jika timestamp sama (terjadi pada frekuensi tulis tinggi), biasanya versi lokal menang.

Merge Strategy — penggabungan versi yang bertentangan

Merge Strategy — pendekatan di mana sistem tidak membuang salah satu versi sepenuhnya, tetapi mencoba menggabungkan perubahan dari keduanya ke dalam keadaan yang konsisten. Ini analog dengan penggabungan cabang di Git: setiap konflik diselesaikan di tingkat bidang atau operasi individu. Strategi Merge dibagi menjadi otomatis (CRDT, OT) dan manual (pengguna memilih varian).

Implementasi yang paling terkenal adalah penggabungan tiga arah (three-way merge). Sistem menyimpan tiga versi: lokal, jarak jauh, dan leluhur bersama mereka (versi dasar sebelum divergensi). Jika suatu bidang hanya diubah oleh satu klien, perubahannya diterima secara otomatis. Jika kedua klien mengubah bidang yang sama — konflik dicatat yang memerlukan penyelesaian. CouchDB dan PouchDB secara aktif menggunakan model ini untuk sinkronisasi dokumen.

Contoh implementasi penggabungan tiga arah untuk profil pengguna:

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

Penggabungan tiga arah efektif ketika struktur data cukup stabil. Masalah muncul saat mengganti nama bidang, mengubah tipe, dan operasi dengan array — dalam kasus ini diperlukan logika yang lebih kompleks.

CRDT — struktur data bebas konflik

CRDT (Conflict-Free Replicated Data Type) — model matematika yang menjamin konvergensi data tanpa koordinator pusat. CRDT dirancang sehingga semua operasi bersifat komutatif: urutan penerapan tidak mempengaruhi hasil akhir. Ini dicapai melalui properti aljabar: penggabungan CRDT selalu memberikan hasil yang sama terlepas dari urutan penerimaan perubahan.

Jenis utama CRDT meliputi G-Counter (penghitung yang hanya mendukung kenaikan), PN-Counter (penghitung dengan kenaikan dan penurunan), LWW-Register (register dengan versioning), dan OR-Set (himpunan yang melacak penambahan dan penghapusan). Setiap jenis menjamin bahwa penggabungan dua replika tidak akan menghasilkan konflik. Menurut penelitian INRIA (Marc Shapiro et al., 2024), CRDT menyediakan konvergensi deterministik untuk 95% tipe data umum.

Contoh G-Counter — penghitung yang hanya dapat dinaikkan:

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 menjamin kebenaran penggabungan karena setiap node hanya menyimpan penghitungnya sendiri, dan merge mengambil maksimum untuk setiap node. Ini adalah contoh klasik struktur bebas konflik yang digunakan dalam sistem terdesentralisasi.

Bagaimana memilih strategi resolusi konflik

Pemilihan strategi tergantung pada sifat data dan skenario penggunaan. LWW optimal untuk aplikasi di mana versi terbaru selalu diprioritaskan — umpan berita, notifikasi, status. Merge Strategy cocok untuk dokumen terstruktur di mana setiap bidang independen — profil pengguna, formulir, konfigurasi. CRDT ideal untuk pengeditan bersama, daftar, dan penghitung dalam sistem terdistribusi.

Saat memilih strategi, tiga faktor dinilai: konsistensi data, kinerja, dan kompleksitas implementasi. LWW memberikan kinerja maksimal dan kompleksitas minimal, tetapi dapat kehilangan data. Merge memberikan akurasi tinggi, tetapi memerlukan mekanisme deteksi perubahan di tingkat bidang. CRDT menjamin kebenaran matematis, tetapi memberlakukan batasan pada tipe data dan ukuran metadata.

Dalam praktiknya, pendekatan kombinasi sering diterapkan: sistem menggunakan LWW untuk metadata, Merge untuk konten dokumen, dan CRDT untuk struktur daftar. Firebase Firestore, misalnya, menerapkan LWW untuk bidang tingkat atas dan mendukung transaksi untuk pembaruan atomik. CouchDB menggunakan Merge dengan penyimpanan riwayat perubahan. Figma dan Notion membangun arsitektur berbasis CRDT untuk pengeditan multi-pengguna waktu nyata.