Perhatikan contoh kasus ini!Tritan memiliki aplikasi web toko online yang menjual produk elektronik. Terpantau, ada 3 buyer sedang mengakses halaman produk yang sama secara bersamaan.
- Buyer 1 lihat stok produk smart TV merek xyz ada 10
- Buyer 2 lihat stok produk smart TV merek xyz ada 10
- Buyer 3 lihat stok produk smart TV merek xyz ada 10
Nah, ketiga buyer tadi mengklik tombol ‘Beli’ di saat yang sama. Jika ketiga permintaan itu dikirim ke server secara bersamaan, kemungkinan buruk apa yang akan terjadi, dan bagaimana cara mengatasinya? Lanjutkan membaca! Setelah kejadian klik tombol ‘Beli’ bersamaan, kemungkinan urutan kejadian yang muncul bisa jadi:
- Buyer 1 – server mengurangi stok produk smart TV merek xyz jadi 9
- Buyer 2 – server mengurangi stok produk smart TV merek xyz jadi 9
- Buyer 3 – server mengurangi stok produk smart TV merek xyz jadi 9
Setelah ketiga permintaan diproses, stok produk smart TV merek xyz tetap menjadi 9. Kondisi ini terjadi karena ketiga permintaan tadi saling bersaing untuk mengurangi stok tanpa melihat jika tindakan satu buyer bisa mempengaruhi aksi buyer lainnya. Kondisi yang terjadi pada kasus tadi dikenal dengan istilah Race Condition. Dalam konteks aplikasi backend, #racecondition muncul jika perilaku atau hasil dari aplikasi tergantung pada waktu / urutan kejadian. Pada aplikasi backend, race condition bisa menjadi masalah serius seperti:
- Korupsi data
- Inkonsistensi, dan
- Kesalahan lain yang bisa berdampak buruk pada fungsionalitas dan performa aplikasi
Dalam konteks transaksi finansial, masalah konsistensi data akibat race condition akan sangat berbahaya. Bahkan, bisa menyebabkan kerugian finansial yang serius. Contoh kasus sederhana, meski sudah melakukan 5 kali transaksi, saldo nasabah hanya berkurang Rp 10.000, padahal harusnya berkurang Rp 50.000.
Berdasarkan kasus itu, Kita simpulkan bahwa perjalanan saldo pada column balance_before dan balance_after mengalami kekacauan. Jadi saldo tidak bergerak sebagaimana mestinya. Penyebabnya karena transaksi terjadi nyaris bersamaan. Sehingga transaksi berikutnya muncul sebelum transaksi sebelumnya menyelesaikan proses update current_balance.
Apa yang bisa tim IT developer lakukan untuk menyelesaikan persoalan tadi?
Pessimistic Locking pada JPA menjadi salah satu solusi yang bisa dipakai untuk mengatasi masalah race condition.
Deleloper backend bisa mengaplikasikan mekanisme sinkronisasi seperti penguncian (locking) atau transaksi atomik. Dengan menerapkan mekanisme sinkronisasi yang tepat, kita dapat menghindari race condition dan memastikan integritas data dalam aplikasi backend. Seperti apa simulasi penerapan Pessimistic Locking pada JPA? Simak pembahasannya pada artikel lain.
Auhor: Herry Pramono