Mencegah Data Ganda Saat Tombol Simpan Ditekan Lagi

Pengguna menekan Simpan, menunggu, lalu menekan lagi karena belum melihat hasil. Pada aplikasi bisnis, kejadian kecil ini dapat menghasilkan dua permintaan untuk maksud yang sama. Tim kemudian harus mencari apakah dua catatan tersebut merupakan duplikasi atau memang dua pekerjaan berbeda.

Masalah ini perlu dibicarakan saat merancang alur web app. Tombol yang dinonaktifkan sementara membantu pengalaman pengguna, tetapi aturan satu tindakan juga perlu dikenali oleh sistem yang memprosesnya. Rancang perilakunya bersama contoh bisnis yang jelas sebelum memilih teknik implementasi.

Tentukan apa yang dianggap satu tindakan

Mulai dari bahasa operasional. “Membuat satu permintaan pembelian” berbeda dari “menambah satu baris barang”. Dua klik mungkin membawa data yang sama, tetapi kesamaan isi saja belum selalu membuktikan bahwa pengguna hanya menginginkan satu tindakan.

Contoh fiktif: operator membuat permintaan PR-017 untuk satu kebutuhan. Jika koneksi terputus setelah server menyimpan, pengiriman ulang seharusnya membantu menemukan hasil PR-017, bukan otomatis membuat PR-018. Sebaliknya, permintaan baru yang sengaja dibuat untuk kebutuhan lain tetap perlu identitasnya sendiri.

Tuliskan pemilik tindakan, objek yang dibuat, kondisi dianggap selesai, dan kapan pengguna boleh memulai tindakan baru. Definisi ini membantu tim membedakan retry dari pekerjaan baru tanpa memakai aturan terlalu luas yang justru menolak kebutuhan sah.

Kenali batas metode dan identitas permintaan

MDN menjelaskan idempotensi sebagai kesamaan efek yang dimaksud pada server ketika permintaan identik diulang. POST tidak otomatis memiliki sifat tersebut. Perilaku aplikasi tetap perlu dirancang sesuai tindakan yang dijalankan.

Identitas percobaan dapat menghubungkan pengiriman pertama dengan pengiriman ulangnya. Dokumentasi Stripe memberi contoh penggunaan kunci idempotensi; aturan penyimpanan dan masa berlakunya merupakan bagian kontrak layanan tersebut. Aplikasi Anda membutuhkan kontrak yang sesuai prosesnya sendiri.

Bicarakan cakupan identitas: apakah untuk satu pengguna, satu organisasi, atau satu transaksi tertentu? Apa yang terjadi jika identitas sama dikirim dengan isi berbeda? Jangan menjadikan nama atau informasi pribadi sebagai identitas yang tersebar di banyak tempat hanya karena mudah diingat.

Tampilkan status tindakan dengan jelas

Setelah pengiriman, tampilkan bahwa tindakan sedang diproses. Pengguna perlu mengetahui apakah sistem menunggu jawaban, sudah menyimpan, atau belum dapat memastikan hasil. Pesan yang sama untuk ketiga keadaan dapat mendorong pengguna mengulangi tindakan tanpa alasan yang jelas.

Saat berhasil, tampilkan identitas hasil atau jalur untuk membukanya. “Tersimpan: PR-017” memberi petunjuk yang dapat ditelusuri. Jika koneksi terputus, pertimbangkan jalur pemeriksaan status sebelum meminta pengguna membuat permintaan baru.

Informasi status harus dapat dipahami tanpa hanya mengandalkan perubahan warna. Beri pesan singkat yang menyebut apa yang terjadi dan langkah berikutnya. Untuk tindakan panjang, jelaskan kapan pengguna dapat meninggalkan halaman sesuai kemampuan aplikasi yang benar-benar tersedia.

Pisahkan hasil utama dari pekerjaan lanjutan

Membuat catatan dapat diikuti pengiriman pemberitahuan atau pembuatan berkas. Putuskan bagaimana setiap pekerjaan dihubungkan ke tindakan utama. Satu catatan yang benar masih dapat menimbulkan kebingungan bila pemberitahuan terkirim berulang tanpa penjelasan.

Contoh: PR-017 berhasil dibuat, tetapi pemberitahuan kepada pemeriksa belum selesai. Status itu berbeda dari kegagalan membuat PR-017. Tim perlu menentukan apakah pemberitahuan dicoba ulang, siapa melihat statusnya, dan bagaimana hasilnya diperiksa.

Jangan menampilkan seluruh tindakan gagal jika catatan utama sebenarnya sudah ada. Sebaliknya, jangan menganggap semua pekerjaan lanjutan selesai hanya karena catatan sudah tersimpan. Pemisahan status membantu operator mengetahui bagian mana yang perlu ditindaklanjuti.

Uji kejadian yang mungkin dialami pengguna

Gunakan lingkungan uji dan data contoh. Coba dua klik cepat, pengiriman ulang setelah menunggu, koneksi terputus sebelum hasil terlihat, serta dua tab yang mengerjakan objek sama. Untuk setiap skenario, tentukan hasil yang diharapkan terlebih dahulu.

Catat jumlah objek yang dibuat, identitas hasil, pesan yang dilihat pengguna, dan pekerjaan lanjutan. Jika pengiriman ulang menghasilkan respons berbeda, periksa apakah efek bisnisnya tetap sesuai definisi satu tindakan.

Tetapkan pula siapa yang memeriksa hasil uji dan bagaimana temuan diterjemahkan menjadi perubahan kontrak tindakan sebelum aplikasi digunakan untuk pekerjaan sebenarnya.

Tambahkan skenario data berubah. Pengguna mungkin mengubah jumlah setelah percobaan pertama. Sistem perlu menjelaskan apakah perubahan menjadi tindakan baru atau harus diselesaikan melalui revisi terhadap hasil lama. Keputusan ini mengikuti alur bisnis, bukan sekadar pilihan tombol.

Masukkan perilaku retry dalam brief

Saat membahas proyek dengan Creatyf, sebut tindakan yang paling merugikan bila tergandakan. Sertakan contoh data, status yang dibutuhkan, dan pihak yang boleh melihat hasil. Hubungkan dengan matriks hak akses agar jalur pemeriksaan hasil tetap menghormati izin pengguna.

Satu tindakan yang dapat dikenali membuat kegagalan koneksi lebih mudah ditangani. Pengguna memperoleh arah yang jelas, sementara tim operasional tidak harus membersihkan data ganda setiap kali jawaban terlambat terlihat.

Sumber resmi

• MDN: Idempotent
• Stripe: Idempotent requests