Race Condition: Saldo 100 Ribu Ditarik 2 Orang Bersamaan, Bank Rugi?

Bayangin Saldo Sisa 100 Ribu...

Bayangin Budi dan Istrinya punya rekening bersama yang saldonya tinggal Rp 100.000. Tepat di milidetik yang sama, Budi menekan tombol tarik tunai di ATM Jakarta, dan istrinya menarik uang di ATM Bandung.

Di Backend, kedua server secara bersamaan mengecek database: "Apakah saldo Budi cukup? Ya, sisa 100 ribu." Karena keduanya mendapat jawaban 'Ya', server membiarkan ATM di Jakarta mengeluarkan 100 ribu, dan ATM di Bandung juga mengeluarkan 100 ribu. Tiba-tiba, saldo Budi di database menjadi minus 100 ribu, dan Bank rugi!

Masalahnya: Race Condition

Fenomena mengerikan di atas disebut Race Condition (Kondisi Balapan). Ini terjadi ketika dua proses (atau lebih) mengakses dan mencoba mengubah data yang sama persis di waktu yang bersamaan. Mesin komputer bergerak terlalu cepat sehingga pengecekan data menjadi tumpang tindih.

Solusinya: Database Locking

Nah, di sinilah konsep Database Locking (Penguncian) masuk. Untuk mencegah Bank bangkrut karena sistem yang tumpang tindih, Backend Developer menggunakan fitur gembok pada database (seperti Pessimistic Locking di SQL).

• Pessimistic Lock: Saat permintaan Budi sampai lebih dulu (walau beda 0.001 detik), database akan langsung MENGGEMBOK baris saldo Budi.
• Saat permintaan Istri Budi masuk, database akan berkata: "Tunggu sebentar! Baris ini sedang dikunci oleh proses lain. Kamu antre dulu!"
• Setelah proses Budi selesai (uang keluar dan saldo di-update jadi 0), gembok dilepas. Barulah permintaan Istrinya diproses. Tapi karena saldo kini sudah 0, server menolak permintaan Istrinya.

Intinya: Aplikasi finansial tidak boleh asal baca-tulis data. Tanpa konsep Locking dan Transaction ACID, Race Condition bisa membuat sistem hancur berantakan saat aplikasi sedang viral.