Berkolaborasi secara konkuren

Pertanyaan

Bagaimana dua orang bisa mengedit dokumen yang sama secara bersamaan dan berakhir di hasil yang sama, tanpa saling menimpa?

Setelah baca ini, kamu bisa menjelaskan kenapa overwrite tidak cukup, apa itu log operasi, bagaimana OT dan CRDT menyelesaikan konflik secara berbeda, dan apa yang tidak mereka jamin.

Prasyarat dan contoh

Kamu sudah paham urutan per percakapan (M13.03), ordering dan konsistensi (M08), serta konflik tulis (M05).

Dokumen berisi abc. Ani menyisipkan X di indeks 1, jadi aXbc. Pada saat yang sama Budi menghapus karakter di indeks 0, jadi bc. Kalau server hanya menerapkan operasi mentah, hasil tergantung urutan datang: Ani lebih dulu lalu hapus indeks 0 menghasilkan Xbc, tapi Budi lebih dulu lalu sisip X di indeks 1 menghasilkan bXc. Dua pengguna melihat dokumen berbeda selamanya.

Mekanisme

Jangan kirim seluruh dokumen. Mengirim snapshot penuh dan "yang terakhir menang" membuang suntingan orang lain. Kirim operasi: insert(posisi, teks) dan delete(posisi, panjang).

Log operasi. Setiap operasi punya identitas (client_id, counter) dan versi dasar: dokumen versi berapa yang dilihat pengirim. Server menyimpan log operasi berurutan. Dokumen = hasil penerapan log dari awal (atau dari snapshot terbaru). Log memberi riwayat, audit, dan jalan untuk mengejar klien yang tertinggal, dengan kursor seperti di chat.

Operational Transform (OT). Server menetapkan urutan operasi. Operasi yang konkuren ditransformasi terhadap operasi yang sudah lebih dulu diterapkan. Contoh tadi: hapus indeks 0 lebih dulu, lalu sisip Ani di indeks 1 harus digeser jadi indeks 0, sehingga hasilnya Xbc di kedua sisi. Kelebihan: representasi dokumen kecil. Kekurangan: fungsi transformasi untuk semua pasangan tipe operasi sulit dibuat benar, dan umumnya butuh server pusat yang menetapkan urutan.

CRDT. Setiap karakter punya identitas unik dan posisi yang stabil (misalnya "setelah karakter id 7 dari klien A"). Operasi bersifat komutatif: diterapkan dalam urutan apa pun, hasilnya sama. Kelebihan: tidak perlu urutan total, cocok untuk edit offline dan peer-to-peer. Kekurangan: metadata per karakter, dan penghapusan sering meninggalkan tombstone. Dokumen 50.000 karakter bisa memegang beberapa kali lipat ukuran teksnya sebagai metadata, dan membersihkannya butuh kompaksi yang perlu disepakati.

Pilihan praktis. Dengan server pusat yang selalu tersedia, OT atau log terurut sederhana sering cukup. Dengan edit offline panjang atau banyak replika, CRDT lebih alami. Banyak tim tidak menulis sendiri, melainkan memakai pustaka yang teruji, karena kedua algoritma terkenal sulit dibuktikan benar.

Snapshot dan kompaksi. Log tumbuh. Ambil snapshot tiap 1.000 operasi atau tiap beberapa menit, simpan, dan operasi lama sebelum snapshot bisa diarsipkan. Klien yang tertinggal jauh memuat snapshot lalu mengejar sisa log. Tetapkan batas retensi log dan prosedur "reset" seperti pada feed.

Otorisasi. Setiap operasi diperiksa: apakah pengirim boleh mengedit dokumen ini? Operasi yang sudah diterapkan sulit dicabut, jadi periksa sebelum masuk log, bukan sesudahnya.

Saat rancangan ini gagal

• Overwrite seluruh dokumen. Dua pengguna menyimpan hampir bersamaan, satu menimpa yang lain tanpa peringatan.
• Indeks tanpa transformasi. Operasi berbasis posisi diterapkan pada versi yang berbeda dari yang dilihat pengirim, dan dokumen bergeser.
• Tombstone tak terkompaksi. Dokumen yang sering diedit membengkak, memuatnya makin lambat, dan kompaksi menjadi proyek besar.
• Edit offline sangat lama. Klien kembali setelah seminggu dengan ratusan operasi, dan hasil penggabungan secara teknis konvergen tapi isinya membingungkan. Perlu tampilan perubahan.
• Operasi tak punya identitas. Retry mengirim operasi dua kali, dan karakter muncul ganda.

Contoh tandingan: formulir pengaturan yang diedit jarang oleh dua admin tidak butuh OT atau CRDT. Cukup versi optimistis (UPDATE ... WHERE version = ?) dan pesan "dokumen berubah, muat ulang" saat konflik.

Latihan

Dokumen abc. Ani menyisipkan X di indeks 1. Konkuren, Budi menghapus karakter di indeks 2 (yaitu c). Server menerima Ani lebih dulu.

1. Berapa hasil yang benar di kedua sisi?
2. Bagaimana operasi Budi ditransformasi?
3. Kapan pendekatan versi optimistis cukup, dan kapan kamu butuh OT atau CRDT?

Lihat pembahasan+

1. Ani: aXbc. Budi menghapus c, jadi hasil akhir yang diinginkan adalah aXb.
2. Setelah operasi Ani diterapkan, c berpindah dari indeks 2 ke indeks 3, karena sisipan di indeks 1 lebih kecil dari 2. Operasi Budi digeser menjadi delete(3), menghasilkan aXb. Di sisi Budi, insert(1, X) milik Ani tetap di indeks 1 karena 1 lebih kecil dari posisi hapus. Hasil aXb di kedua sisi.
3. Versi optimistis cukup bila konflik jarang dan menolak lalu meminta muat ulang itu bisa diterima (formulir, pengaturan). OT atau CRDT dibutuhkan bila banyak orang mengetik di teks yang sama secara terus-menerus, dan menolak suntingan itu tidak bisa diterima.

Terkait

• Sebelumnya: M13.05 Buat feed.
• Kursor dan pemulihan dari log juga dipakai di M13.03 Kirim pesan chat.
• Konsep ordering dari M08 dan konflik tulis dari M05 menjadi dasar. Rancangan D16 belum tersedia.

Catatan

• Asumsi: teks sederhana dengan sisip dan hapus, bukan dokumen kaya dengan struktur bersarang.
• Pengantar saja. Algoritma OT dan CRDT tertentu, undo bersama, dan format penyimpanan tidak dibahas rinci.
• Angka ukuran metadata CRDT bergantung pada implementasi. Ukur pustaka yang kamu pakai.
• Terakhir ditinjau: 26 Oktober 2026.