Optimistic Locking: Kenapa Perubahan Adminmu Bisa Hilang Ditimpa Admin Lain?

Bayangin Dua Admin Edit Stok Produk yang Sama...

Bayangin Siti membuka halaman edit produk "Sepatu Lari", melihat stok tertulis 50, lalu sibuk mengetik deskripsi baru selama 2 menit sebelum menekan Simpan. Di saat bersamaan, Budi juga membuka halaman yang sama, melihat stok 50 yang sama, buru-buru mengubahnya menjadi 30 (karena baru saja ada pesanan masuk), dan menekan Simpan lebih dulu — berhasil.

Dua menit kemudian, Siti menekan tombol Simpan miliknya. Aplikasi bilang "Berhasil disimpan!" — tapi karena form Siti masih menyimpan nilai stok lama (50) sejak dia pertama membuka halaman, perubahan stok Budi menjadi 30 tadi tertimpa balik menjadi 50, seolah pesanan Budi tidak pernah masuk!

Masalahnya: 'Lost Update' — Database Tidak Tahu Siapa yang Datanya Lebih Baru

Database secara default tidak punya konsep "data ini sudah pernah diubah orang lain sejak saya membacanya." Setiap UPDATE hanya menimpa nilai apapun yang ada di kolom itu saat perintah dieksekusi, siapapun yang terakhir menekan Simpan yang menang — walau datanya sebenarnya sudah usang (stale). Masalah ini disebut Lost Update, dan sangat berbahaya untuk data seperti stok, saldo, atau status pesanan.

Nah, Di Sinilah 'Optimistic Locking' Masuk!

Optimistic Locking menambahkan satu kolom kecil bernama version (angka, dimulai dari 0) pada tabel, dan mengubah cara UPDATE bekerja:

1. Saat Siti dan Budi sama-sama membuka data, mereka sama-sama menerima version: 5 beserta data stoknya.
2. Saat Budi menyimpan lebih dulu, query-nya menjadi: UPDATE products SET stock = 30, version = 6 WHERE id = 'sepatu-lari' AND version = 5. Karena version di database masih 5, update ini berhasil, dan version di database sekarang naik jadi 6.
3. Saat Siti menyimpan, query miliknya juga mencoba: UPDATE products SET description = '...', version = 6 WHERE id = 'sepatu-lari' AND version = 5. Tapi version di database sudah menjadi 6, bukan 5 lagi — jadi klausa WHERE tidak menemukan baris manapun yang cocok, 0 baris ter-update, dan aplikasi tahu harus menampilkan pesan: "Data ini sudah diubah orang lain, silakan muat ulang."

// Contoh dengan Prisma
await prisma.product.update({
  where: { id: productId, version: currentVersion },
  data: { stock: newStock, version: { increment: 1 } },
});
// Jika 0 baris ter-update, lempar error "Conflict, silakan refresh"

Intinya: Optimistic Locking tidak mencegah dua orang mengedit bersamaan (tidak ada kunci yang benar-benar mengunci), tapi memastikan salah satunya ditolak dengan jelas alih-alih diam-diam kehilangan perubahannya. Cocok dipakai di fitur yang jarang bentrok tapi fatal kalau sampai bentrok, seperti data stok atau saldo.