Penguncian optimistik untuk alat admin: hindari penimpaan senyap

Masalah: penimpaan senyap saat banyak orang mengedit

"Penimpaan senyap" terjadi ketika dua orang membuka rekaman yang sama, keduanya melakukan perubahan, dan orang terakhir yang menekan Simpan menang. Perubahan orang pertama hilang tanpa peringatan dan sering tanpa cara mudah untuk memulihkannya.

Di panel admin yang sibuk, ini bisa terjadi sepanjang hari tanpa ada yang menyadari. Orang membuka banyak tab, bolak-balik antar tiket, dan kembali ke form yang sudah terbuka 20 menit. Saat akhirnya menyimpan, mereka tidak memperbarui versi rekaman terbaru. Mereka menimpanya.

Masalah ini lebih sering muncul di alat back-office daripada aplikasi publik karena pekerjaan bersifat kolaboratif dan berbasis rekaman. Tim internal sering mengedit pelanggan, pesanan, produk, dan permintaan yang sama berulang kali, sering dalam rentetan singkat. Aplikasi publik lebih sering "satu pengguna mengedit miliknya sendiri", sementara alat admin adalah "banyak pengguna mengedit hal bersama."

Dampaknya jarang dramatis dalam momen itu, tapi cepat menumpuk:

• Harga produk kembali ke nilai lama tepat setelah pembaruan promo.
• Catatan internal agen support hilang, sehingga agen berikutnya mengulangi langkah troubleshooting yang sama.
• Status pesanan bergeser mundur (mis. dari "Shipped" kembali ke "Packed"), memicu tindak lanjut yang salah.
• Nomor telepon atau alamat pelanggan diganti dengan info usang.

Penimpaan senyap menyakitkan karena semua orang mengira sistem menyimpan dengan benar. Tidak ada momen jelas “ada yang salah”, hanya kebingungan nanti saat laporan terlihat aneh atau rekan bertanya, “Siapa yang mengubah ini?”

Konflik seperti ini normal. Itu tanda alat digunakan bersama dan berguna, bukan tanda tim Anda berbuat salah. Tujuannya bukan menghentikan dua orang mengedit. Tujuannya mendeteksi ketika rekaman berubah saat seseorang sedang mengedit, lalu menangani momen itu dengan aman.

Jika Anda membangun alat internal di platform tanpa kode seperti AppMaster, ada baiknya merencanakannya sejak dini. Alat admin cenderung tumbuh cepat, dan setelah tim bergantung padanya, kehilangan data “kadang-kadang” berubah menjadi sumber ketidakpercayaan yang konstan.

Optimistic locking dalam bahasa sederhana

Saat dua orang membuka rekaman yang sama dan keduanya menekan Simpan, Anda punya masalah konkurensi. Masing-masing memulai dari snapshot lama, tetapi hanya satu yang bisa menjadi “terbaru” ketika penyimpanan terjadi.

Tanpa perlindungan, penyimpanan terakhir menang. Begitulah penimpaan senyap terjadi: penyimpanan kedua menggantikan perubahan orang pertama tanpa suara.

Optimistic locking adalah aturan sederhana: “Saya akan menyimpan perubahan saya hanya jika rekaman masih dalam keadaan yang sama seperti saat saya mulai mengedit.” Jika rekaman berubah di tengah, penyimpanan ditolak dan pengguna melihat konflik.

Ini berbeda dari pessimistic locking, yang lebih mirip “saya sedang mengedit ini, jadi tidak ada yang boleh.” Pessimistic locking biasanya berarti kunci keras, timeout, dan orang terblokir. Itu bisa berguna dalam kasus langka (mis. memindahkan uang antar rekening), tetapi sering membuat frustasi di alat admin sibuk di mana banyak edit kecil terjadi sepanjang hari.

Optimistic locking biasanya pilihan default yang lebih baik karena menjaga alur kerja tetap berjalan. Orang dapat mengedit paralel, dan sistem hanya turun tangan saat ada tabrakan nyata.

Cocok ketika:

• Konflik mungkin tapi tidak konstan.
• Edit cepat (beberapa field, form pendek).
• Memblokir orang lain akan memperlambat tim.
• Anda dapat menampilkan pesan jelas “seseorang memperbarui ini”.
• API Anda bisa memeriksa versi (atau timestamp) setiap kali update.

Yang dicegah adalah masalah “penimpaan senyap”. Alih-alih kehilangan data, Anda mendapatkan berhenti yang bersih: “Rekaman ini berubah sejak Anda membukanya.”

Yang tidak bisa dilakukan juga penting. Ia tidak akan menghentikan dua orang membuat keputusan berbeda (tapi valid) berdasarkan informasi lama, dan ia tidak otomatis menggabungkan perubahan untuk Anda. Dan jika Anda melewatkan pemeriksaan di sisi server, Anda belum benar-benar menyelesaikan apa-apa.

Batas umum yang harus diingat:

• Ia tidak akan menyelesaikan konflik secara otomatis (Anda masih perlu memilih).
• Ia tidak membantu jika pengguna mengedit offline lalu sinkron tanpa pemeriksaan.
• Ia tidak memperbaiki izin yang buruk (seseorang masih bisa mengedit yang seharusnya tidak boleh).
• Ia tidak menangkap konflik jika hanya diperiksa di klien.

Dalam praktiknya, optimistic locking hanyalah satu nilai tambahan yang dibawa dengan edit, plus aturan di sisi server “hanya update jika cocok”. Jika Anda membangun panel admin di AppMaster, pemeriksaan ini biasanya ada di logika bisnis tepat di tempat update dieksekusi.

Dua pendekatan umum: kolom version vs updated_at

Untuk mendeteksi bahwa rekaman berubah saat seseorang mengeditnya, Anda biasanya memilih salah satu dari dua sinyal: nomor versi atau timestamp updated_at.

Pendekatan 1: kolom Version (integer yang bertambah)

Tambahkan field version (biasanya integer). Saat membuka form edit, Anda juga memuat version saat ini. Saat menyimpan, kirimkan nilai itu kembali.

Update hanya berhasil jika versi yang tersimpan masih cocok dengan yang user mulai. Jika cocok, Anda memperbarui rekaman dan menambah version sebesar 1. Jika tidak cocok, kembalikan konflik alih-alih menimpa.

Ini mudah dipahami: version 12 berarti “ini perubahan ke-12.” Ini juga menghindari edge case terkait waktu.

Pendekatan 2: updated_at (perbandingan timestamp)

Sebagian besar tabel sudah memiliki field updated_at. Ide nya sama: baca updated_at saat form dibuka, lalu sertakan saat menyimpan. Server hanya mengupdate jika updated_at tidak berubah.

Ini bisa bekerja baik, tetapi timestamp punya perangkap. Database berbeda menyimpan presisi berbeda. Beberapa membulat ke detik, yang bisa melewatkan edit cepat. Jika beberapa sistem menulis ke database yang sama, drift jam dan penanganan zona waktu juga bisa menimbulkan edge case membingungkan.

Cara sederhana untuk membandingkan:

• Kolom version: perilaku paling jelas, portabel antar database, tanpa masalah jam.
• updated_at: sering “gratis” karena sudah ada, tapi presisi dan penanganan jam dapat menyulitkan.

Untuk kebanyakan tim, kolom version adalah sinyal primer yang lebih baik. Ia eksplisit, dapat diprediksi, dan mudah direferensikan di log dan tiket support.

Jika Anda membangun di AppMaster, ini biasanya berarti menambahkan field integer version di Data Designer dan memastikan logika update Anda memeriksanya sebelum menyimpan. Anda bisa tetap menyimpan updated_at untuk audit, tetapi biarkan nomor versi yang menentukan apakah edit aman untuk diterapkan.

Apa yang disimpan dan apa yang dikirim dengan setiap edit

Optimistic locking hanya bekerja jika setiap edit membawa penanda “terakhir dilihat” dari saat pengguna membuka form. Penanda itu bisa version atau updated_at. Tanpanya, server tidak bisa tahu apakah rekaman berubah saat pengguna mengetik.

Pada rekaman itu sendiri, simpan field bisnis normal, plus satu field konkurensi yang dikendalikan server. Set minimum terlihat seperti ini:

• id (identifier stabil)
• field bisnis (name, status, price, notes, dll.)
• version (integer yang bertambah setiap update sukses) atau updated_at (timestamp yang ditulis server)

Saat layar edit dimuat, form harus menyimpan nilai last-seen dari field konkurensi itu. Pengguna tidak boleh mengubahnya, jadi simpan sebagai field tersembunyi atau dalam state form. Contoh: API mengembalikan version: 12, dan form menyimpan 12 sampai Simpan.

Saat pengguna menekan Simpan, kirim dua hal: perubahan dan penanda last-seen. Bentuk paling sederhana adalah menyertakannya di body request update, seperti id, field yang diubah, dan expected_version (atau expected_updated_at). Jika Anda membangun UI di AppMaster, perlakukan ini seperti nilai terikat lain: muat bersama rekaman, simpan tanpa diubah, dan submit kembali saat update.

Di server, update harus kondisional. Anda hanya mengupdate jika marker yang diharapkan cocok dengan apa yang ada di database. Jika tidak cocok, jangan “merge” diam-diam.

Response konflik harus jelas dan mudah ditangani di UI. Response konflik praktis mencakup:

• HTTP status 409 Conflict
• pesan singkat seperti “Rekaman ini diperbarui oleh orang lain.”
• nilai server saat ini (current_version atau current_updated_at)
• opsional, rekaman server saat ini (agar UI bisa menunjukkan apa yang berubah)

Contoh: Sam membuka record Customer pada version 12. Priya menyimpan perubahan, menjadikannya version 13. Sam kemudian menekan Simpan dengan expected_version: 12. Server mengembalikan 409 dengan rekaman saat ini version 13. Sekarang UI dapat meminta Sam meninjau nilai terbaru alih-alih menimpa edit Priya.

Langkah demi langkah: implementasikan optimistic locking end to end

Optimistic locking pada dasarnya aturan sederhana: setiap edit harus membuktikan bahwa itu berdasarkan versi terbaru rekaman yang tersimpan.

1) Tambahkan field konkurensi

Pilih satu field yang berubah pada setiap write.

version integer khusus paling mudah dipahami. Mulai di 1 dan tambah tiap update. Jika sudah punya updated_at andal yang selalu berubah, Anda bisa gunakan itu, tetapi pastikan itu berubah pada setiap write (termasuk job latar belakang).

2) Kirim nilai itu ke klien saat membaca

Saat UI membuka layar edit, sertakan version (atau updated_at) saat ini di response. Simpan di state form sebagai nilai tersembunyi.

Pikirkan ini sebagai bukti terima: “Saya sedang mengedit yang terakhir saya baca.”

3) Wajibkan nilai itu saat update

Saat menyimpan, klien mengirim field yang diedit plus nilai konkurensi last-seen.

Di server, buat update kondisional. Dalam istilah SQL, itu:

UPDATE tickets
SET status = $1,
    version = version + 1
WHERE id = $2
  AND version = $3;

Jika update memengaruhi 1 row, penyimpanan berhasil. Jika 0 row, seseorang sudah mengubah rekaman.

4) Kembalikan nilai baru setelah sukses

Setelah penyimpanan sukses, kembalikan rekaman yang diperbarui dengan version baru (atau updated_at baru). Klien harus mengganti state form dengan apa yang dikembalikan server. Ini mencegah “double save” menggunakan versi lama.

5) Perlakukan konflik sebagai hasil normal

Saat update kondisional gagal, kembalikan response konflik yang jelas (sering HTTP 409) yang menyertakan:

• rekaman server saat ini
• perubahan yang dicoba klien (atau cukup info untuk merekonstruksinya)
• field mana yang berbeda (jika bisa dihitung)

Di AppMaster, ini cocok dengan field model PostgreSQL di Data Designer, endpoint read yang mengembalikan version, dan Business Process yang melakukan update kondisional dan bercabang ke penanganan sukses atau konflik.

Pola UI yang menangani konflik tanpa mengganggu pengguna

Optimistic locking hanya separuh pekerjaan. Separuh lainnya adalah apa yang dilihat pengguna saat penyimpanannya ditolak karena orang lain mengubah rekaman.

UI konflik yang baik punya dua tujuan: menghentikan penimpaan senyap, dan membantu pengguna menyelesaikan tugasnya dengan cepat. Jika dikerjakan baik, terasa seperti pagar pengaman yang membantu, bukan hambatan.

Pola 1: Dialog blocking sederhana (paling cepat)

Gunakan ini saat edit kecil, dan pengguna bisa dengan aman menerapkan ulang perubahan setelah reload.

Buat pesan singkat dan spesifik: “Rekaman ini berubah saat Anda mengedit. Reload untuk melihat versi terbaru.” Lalu berikan dua aksi jelas:

• Reload dan lanjutkan (primary)
• Salin perubahan saya (opsional tapi membantu)

"Salin perubahan saya" bisa menaruh nilai yang belum tersimpan ke clipboard atau mempertahankannya di form setelah reload, sehingga orang tidak harus mengingat apa yang mereka ketik.

Ini cocok untuk update satu field, toggle, perubahan status, atau catatan pendek. Juga paling mudah diimplementasikan di banyak builder, termasuk layar admin berbasis AppMaster.

Pola 2: "Review changes" (terbaik untuk rekaman bernilai tinggi)

Gunakan ini saat rekaman penting (harga, izin, payout, pengaturan akun) atau form panjang. Alih-alih error buntu, arahkan pengguna ke layar konflik yang membandingkan:

• "Perubahan Anda" (apa yang mereka coba simpan)
• "Nilai saat ini" (terbaru dari database)
• "Apa yang berubah sejak Anda membuka" (field yang bertabrakan)

Fokuskan tampilannya. Jangan tunjukkan semua field jika hanya tiga field yang konflik.

Untuk tiap field yang konflik, tawarkan pilihan sederhana:

• Pertahankan milik saya
• Ambil milik mereka
• Gabungkan (hanya bila masuk akal, mis. tags atau catatan)

Setelah pengguna menyelesaikan konflik, simpan lagi dengan nilai version terbaru. Jika mendukung rich text atau catatan panjang, tampilkan diff kecil (tambah/hapus teks) agar pengguna bisa cepat memutuskan.

Kapan mengizinkan forced overwrite (dan siapa yang boleh)

Kadang forced overwrite dibutuhkan, tetapi harus jarang dan terkendali. Jika menambahkannya, buat sengaja: minta alasan singkat, catat siapa yang melakukannya, dan batasi pada peran seperti admin atau supervisor.

Untuk pengguna biasa, default ke “Review changes.” Forced overwrite paling dapat dibenarkan bila pengguna pemilik rekaman, rekaman berisiko rendah, atau sistem memperbaiki data buruk di bawah pengawasan.

Contoh skenario: dua rekan kerja mengedit rekaman yang sama

Dua agen support, Maya dan Jordan, bekerja di alat admin yang sama. Keduanya membuka profil pelanggan yang sama untuk memperbarui status dan menambah catatan setelah panggilan terpisah.

Timeline (dengan optimistic locking aktif menggunakan version atau pemeriksaan updated_at):

• 10:02 - Maya membuka Customer #4821. Form memuat Status = "Needs follow-up", Notes = "Called yesterday" dan Version = 7.
• 10:03 - Jordan membuka pelanggan yang sama. Ia melihat data yang sama, juga Version = 7.
• 10:05 - Maya mengubah Status menjadi "Resolved" dan menambah catatan: "Issue fixed, confirmed by customer." Ia menekan Simpan.
• 10:05 - Server memperbarui rekaman, menaikkan Version ke 8 (atau memperbarui updated_at), dan menyimpan entri audit: siapa mengubah apa dan kapan.
• 10:09 - Jordan mengetik catatan berbeda: "Customer asked for a receipt" dan menekan Simpan.

Tanpa pemeriksaan konkurensi, penyimpanan Jordan bisa saja menimpa status dan catatan Maya, tergantung bagaimana update dibangun. Dengan optimistic locking, server menolak update Jordan karena ia mencoba menyimpan Version = 7 sementara rekaman sudah di Version = 8.

Jordan melihat pesan konflik jelas. UI menunjukkan apa yang terjadi dan memberi langkah aman:

• Reload rekaman terbaru (buang edit saya)
• Terapkan perubahan saya di atas rekaman terbaru (direkomendasikan bila memungkinkan)
• Tinjau perbedaan (tampilkan "Milik Saya" vs "Terbaru") dan pilih yang dipertahankan

Layar sederhana bisa menunjukkan:

• "Customer ini diperbarui oleh Maya pada 10:05"
• Field yang berubah (Status dan Notes)
• Pratinjau catatan Jordan yang belum disimpan, sehingga ia bisa menyalin atau menerapkannya kembali

Jordan memilih “Review differences,” mempertahankan Status Maya = "Resolved", dan menambahkan catatannya ke catatan yang ada. Ia menyimpan lagi, kali ini menggunakan Version = 8, dan update berhasil (sekarang Version = 9).

Keadaan akhir: tidak ada kehilangan data, tidak ada tebak-tebakan siapa yang menimpa siapa, dan jejak audit yang jelas menunjukkan perubahan status Maya dan kedua catatan sebagai edit terpisah yang dapat ditelusuri. Di alat yang dibangun dengan AppMaster, ini terpeta rapi ke satu pemeriksaan pada update plus dialog resolusi konflik kecil di UI admin.

Kesalahan umum yang masih menyebabkan kehilangan data

Sebagian besar bug “optimistic locking” bukan tentang idenya. Mereka muncul di antar muka antara UI, API, dan database. Jika satu lapisan lupa aturan, Anda masih bisa mendapatkan penimpaan senyap.

Kesalahan klasik adalah mengambil versi (atau timestamp) saat layar edit dimuat, tetapi tidak mengirimkannya kembali saat menyimpan. Ini sering terjadi saat form digunakan ulang antar halaman dan field tersembunyi terlepas, atau saat klien API hanya mengirim field yang “berubah.”

Perangkap umum lain adalah melakukan pemeriksaan konflik hanya di browser. Pengguna mungkin melihat peringatan, tetapi jika server tetap menerima update, klien lain (atau retry) bisa menimpa data. Server harus menjadi penjaga terakhir.

Pola yang paling menyebabkan kehilangan data:

• Token konkurensi hilang di request simpan (version, updated_at, atau ETag), jadi server tidak punya yang dibandingkan.
• Menerima update tanpa kondisi atomik, seperti meng-update hanya berdasarkan id bukan “id + version.”
• Menggunakan updated_at dengan presisi rendah (mis. detik). Dua edit dalam detik yang sama bisa terlihat identik.
• Mengganti field besar (notes, deskripsi) atau seluruh array (tags, line items) tanpa memperlihatkan apa yang berubah.
• Menganggap setiap konflik cukup di-"retry", yang bisa menerapkan nilai usang di atas data yang lebih baru.

Contoh konkret: dua lead support membuka rekaman pelanggan yang sama. Satu menambah catatan internal panjang, yang lain mengubah status dan menyimpan. Jika penyimpanan Anda menimpa seluruh payload rekaman, perubahan status bisa tanpa sengaja menghapus catatan.

Saat konflik terjadi, tim masih kehilangan data jika response API terlalu tipis. Jangan hanya mengembalikan “409 Conflict.” Kembalikan cukup info agar manusia bisa memperbaikinya:

• Versi server saat ini (atau updated_at)
• Nilai server terbaru untuk field yang terlibat
• Daftar field yang berbeda (bahkan nama sederhana)
• Siapa yang mengubah dan kapan (jika Anda melacaknya)

Jika mengimplementasikan di AppMaster, terapkan disiplin yang sama: simpan version di state UI, kirimkan dengan update, dan tegakkan pemeriksaan di logika backend sebelum menulis ke PostgreSQL.

Pemeriksaan cepat sebelum produksi

Sebelum rollout, lakukan pengecekan cepat terhadap mode kegagalan yang menyebabkan “terlihat tersimpan” sambil diam-diam menimpa kerja orang lain.

Pemeriksaan Data dan API

Pastikan rekaman membawa token konkurensi end-to-end. Token itu bisa version integer atau updated_at timestamp, tetapi harus diperlakukan sebagai bagian rekaman, bukan metadata opsional.

• Read menyertakan token (dan UI menyimpannya di state form, bukan hanya di layar).
• Setiap update mengirimkan token last-seen, dan server memverifikasinya sebelum menulis.
• Saat sukses, server mengembalikan token baru agar UI tetap sinkron.
• Edit massal dan inline mengikuti aturan yang sama, bukan jalan pintas khusus.
• Job latar belakang yang mengedit baris yang sama juga memeriksa token (atau mereka akan menciptakan konflik yang tampak acak).

Jika membangun di AppMaster, pastikan field di Data Designer ada (version atau updated_at), dan Business Process update Anda membandingkannya sebelum melakukan write ke database.

Pemeriksaan UI

Konflik hanya “aman” jika langkah selanjutnya jelas.

Saat server menolak update, tampilkan pesan jelas seperti: “Rekaman ini berubah sejak Anda membukanya.” Lalu tawarkan satu aksi aman pertama: reload data terbaru. Jika memungkinkan, tambahkan jalur “reload dan terapkan ulang” yang mempertahankan input pengguna dan menerapkannya ke rekaman yang diperbarui, sehingga perbaikan kecil tidak menjadi sesi mengetik ulang.

Jika tim benar-benar membutuhkannya, tambahkan opsi “force save” yang terkendali. Batasi dengan peran, konfirmasi, dan catat siapa yang memaksa serta apa yang berubah. Itu memungkinkan darurat tanpa menjadikan kehilangan data sebagai default.

Langkah berikutnya: tambahkan locking ke satu alur kerja lalu perluas

Mulai kecil. Pilih satu layar admin di mana orang sering saling bertabrakan, dan tambahkan optimistic locking di sana dulu. Area bertrafik tinggi biasanya tiket, pesanan, harga, dan inventori. Jika Anda membuat konflik aman di satu layar sibuk, Anda akan segera melihat pola yang bisa diterapkan di tempat lain.

Pilih perilaku konflik default di awal, karena itu membentuk logika backend dan UI:

• Block-and-reload: hentikan penyimpanan, reload rekaman terbaru, dan minta pengguna menerapkan ulang perubahan.
• Review-and-merge: tunjukkan “perubahan Anda” vs “perubahan terbaru” dan biarkan pengguna memilih yang dipertahankan.

Block-and-reload lebih cepat dibangun dan cocok saat edit pendek. Review-and-merge layak untuk rekaman panjang atau bernilai tinggi.

Kemudian implementasikan dan uji satu alur lengkap sebelum memperluas:

• Pilih satu layar dan daftarkan field yang paling sering diedit.
• Tambahkan nilai version (atau updated_at) ke payload form dan wajibkan saat menyimpan.
• Buat update kondisional di penulisan database (hanya update jika version cocok).
• Desain pesan konflik dan langkah selanjutnya (reload, copy text, buka tampilan perbandingan).
• Uji dengan dua browser: simpan di tab A, lalu coba simpan data usang di tab B.

Tambahkan logging ringan untuk konflik. Bahkan event "conflict happened" sederhana dengan tipe rekaman, nama layar, dan peran pengguna membantu menemukan hotspot.

Jika Anda membangun alat admin dengan AppMaster (appmaster.io), bagian utama terpeta rapi: modelkan field version di Data Designer, tegakkan update kondisional di Business Processes, dan tambahkan dialog konflik kecil di UI builder. Setelah alur kerja pertama stabil, ulangi pola yang sama layar demi layar, dan pertahankan UI konflik konsisten agar pengguna mempelajarinya sekali dan mempercayainya di mana-mana.