PayStory — Race Condition alias Balapan Yang Bisa Menjadi Liar

Sandi Fajariadi
5 min readMar 13, 2024

Pernahkah Anda terjebak dalam kerumunan yang padat, berusaha untuk membayar sesuatu di tempat yang sedang ramai dikunjungi? Bayangkan Anda berada di sebuah restoran yang sedang hits, tempat ini dipenuhi oleh pengunjung yang bersemangat. Dalam situasi seperti ini, kesabaran sering kali diuji — banyak dari mereka yang enggan untuk mengantre dengan tertib. Mereka berkumpul di sekitar kasir, masing-masing dengan tekad bulat ingin dilayani terlebih dahulu. Tugas kasir menjadi semakin menantang, bukan hanya karena harus menghadapi keramaian, tetapi juga kesulitan untuk memastikan setiap transaksi dapat diidentifikasi dan diproses dengan akurat, terutama ketika beberapa pembeli ternyata membayar dengan jumlah yang identik.

Potensi terjadinya human error menjadi sangat tinggi, dengan risiko yang meliputi kemungkinan kesalahan dalam menetapkan transaksi yang telah diselesaikan. Akibatnya, dapat terjadi situasi di mana seseorang telah melakukan pembayaran, namun transaksi yang dicatat bukanlah milik mereka, atau sebaliknya, seseorang belum membayar namun transaksi mereka telah ditandai sebagai terbayar.

Situasi serupa dapat terjadi dalam lingkup digital, seperti dalam proses penerimaan transfer masuk pada sistem perbankan. Ambil contoh rekening milik Fulan, yang memiliki saldo awal sebesar 100.000. Kemudian, Fulan menginisiasi kampanye donasi “Koin untuk Fulan”, menarik banyak orang untuk berkontribusi. Dalam sebuah momen serentak, lima individu melakukan transfer ke rekening Fulan, masing-masing sejumlah 10.000. Secara logis, dengan lima donasi sebesar 10.000, total sumbangan yang seharusnya diterima oleh Fulan adalah 50.000, yang akan meningkatkan saldo rekeningnya menjadi 150.000.

Namun, akibat kesalahan dalam penanganan dan logika sistem, kelima permintaan transfer tersebut secara keliru menginterpretasikan saldo awal Fulan sebagai 100.000. Akibatnya, setiap permintaan salah mengasumsikan bahwa mereka perlu menambahkan 10.000 ke 100.000, sehingga menghasilkan total 110.000 untuk setiap transaksi. Ini menyebabkan saldo Fulan tidak bertambah menjadi 150.000 seperti yang diharapkan, melainkan hanya menjadi 110.000. Fenomena ini dikenal sebagai Race Condition, di mana kesalahan koordinasi dalam pemrosesan data bersamaan menghasilkan keluaran yang tidak akurat.

Race Condition terjadi ketika dua atau lebih proses atau transaksi berusaha mengakses dan memodifikasi suatu data secara bersamaan tanpa koordinasi yang tepat, sehingga hasil akhirnya tidak dapat diprediksi atau bahkan salah. Dalam konteks sistem pembayaran digital, hal ini dapat menimbulkan kesalahan seperti kegagalan proses, masalah di pencatatan saldo akun pengguna atau kesalahan menetapkan status suatu transaksi.

Untuk mengatasi masalah Race Condition, diperlukan strategi pengelolaan yang komprehensif dan solusi teknis yang matang.

Beberapa pendekatan yang bisa diadopsi meliputi penggunaan mekanisme penguncian yang memastikan hanya satu transaksi yang bisa mengakses sumber daya pada satu waktu, serta implementasi antrian transaksi yang menjamin proses pembaruan data berlangsung secara berurutan dan terkontrol.

Sebagai contoh, dalam beberapa sistem manajemen basis data (DB Engine), telah dikembangkan metode untuk mengunci baris tertentu yang datanya akan diubah, dimulai dari saat data tersebut pertama kali diambil dengan menggunakan perintah SELECT … FOR UPDATE. Melalui pendekatan ini, apabila terdapat proses lain yang berusaha memodifikasi data yang sama dengan menjalankan query yang identik, maka proses tersebut harus menunggu hingga query yang sedang berlangsung selesai. Dalam situasi di mana proses yang menunggu terlalu lama karena melebihi batas waktu maksimal yang ditentukan, proses tersebut berpotensi gagal karena query yang sedang berjalan belum mencapai penyelesaian.

Alternatif lain melibatkan penerapan sistem antrian menggunakan engine seperti Kafka atau RabbitMQ, yang memungkinkan proses untuk dikelola secara berurutan, tidak peduli seberapa banyak permintaan yang masuk. Dengan sistem ini, setiap proses akan ditempatkan dalam antrian dan diproses satu demi satu. Namun, ketika volume antrian meningkat, bisa terjadi keterlambatan dalam pemrosesan, terutama untuk item di bagian akhir antrian. Ada kemungkinan juga bahwa beberapa proses mungkin sudah melewati batas waktu yang ditetapkan (jika ada batas waktu) sebelum sempat diproses.

Ada beberapa cara lainnya juga yang bisa digunakan, yg pasti harus bisa memastikan bahwa multiple request yang datang bersamaan bisa ditangani dengan baik.

Setiap proses mempunyai plus dan minus nya. Mana yang lebih baik tentunya yang sesuai dengan kebutuhan di tempat masing-masing.

Sebagian besar layanan saat ini mengadopsi teknologi API berbasis Web Service yang memungkinkan pengolahan permintaan secara paralel dan multi-thread. Ditambah lagi, di sisi back end, banyak yang telah beralih ke penggunaan Microservices, di mana setiap container dapat bekerja secara paralel untuk mengelola setiap permintaan yang diterima. Dengan demikian, penting bagi penyedia layanan untuk memastikan bahwa sistemnya mampu mengelola akses simultan ke data yang sama, terlepas dari kompleksitas arsitektur yang digunakan.

Penting bagi penyedia layanan untuk menerapkan praktik terbaik dalam pengembangan sistem, termasuk pengujian komprehensif untuk mengidentifikasi dan mengatasi potensi Race Condition sebelum sistem diimplementasikan secara luas.

Race Condition memang menimbulkan tantangan yang signifikan dalam operasional sistem pembayaran digital. Namun, dengan pemahaman yang mendalam dan penerapan solusi yang tepat, masalah ini dapat diatasi. Langkah strategis dalam mengelola dan mencegah Race Condition tidak hanya akan meningkatkan keandalan dan keamanan sistem pembayaran digital, tetapi juga memperkuat kepercayaan pengguna terhadap teknologi keuangan.

Sering kali, saya mengamati bahwa banyak pengembang mendesain dan menguji sistem dalam kondisi standar, di mana permintaan diproses secara bertahap satu demi satu. Kode yang mereka kembangkan seringkali belum dioptimalkan untuk mengelola beban permintaan yang tinggi atau untuk beroperasi dalam lingkungan Microservices. Ini berakar pada asumsi bahwa semua permintaan yang diterima akan bersifat normal dan wajar. Selain itu, tim Quality Assurance (QA) sering kali mengabaikan untuk menjalankan skenario pengujian anomali atau bahkan mengesampingkan pentingnya stress test. Ini menciptakan kesenjangan dalam kesiapan sistem untuk menghadapi kondisi operasional yang sesungguhnya.

Sebagai orang produk, Anda bertanggung jawab untuk memastikan bahwa dalam tahap User Acceptance Test (UAT), sistem yang dikembangkan mampu mengelola sejumlah besar permintaan secara simultan. Penting juga untuk menekankan pentingnya melakukan Stress Test pada komponen logika kritis, guna memastikan keandalan sistem.

Langkah ini tidak hanya sebagai pengingat, tetapi juga sebagai jaminan kepada tim pengembang dan pengujian bahwa produk yang dihasilkan dapat diandalkan dalam kondisi operasional yang intens.

Dalam situasi di mana tim produk tidak tersedia, penting untuk memastikan bahwa individu yang bertanggung jawab atas pengembangan produk memiliki pemahaman yang komprehensif tentang berbagai skenario yang mungkin terjadi. Mereka harus mampu menyampaikan pemahaman tersebut kepada tim pengembang, memastikan bahwa sistem yang dibangun siap menghadapi berbagai kemungkinan operasional.

Jadi, ketika Anda mengembangkan atau menggunakan sistem pembayaran digital, jangan hanya fokus pada kecepatan; perhatikan juga keamanan dan akurasi.

Seperti yang dikatakan oleh Albert Einstein, “Kita tidak bisa memecahkan masalah dengan cara berpikir yang sama saat kita menciptakannya.”

Jadi, ingatlah, dalam lomba kecepatan transaksi, bukan hanya seberapa cepat transaksi anda berlari, tetapi seberapa baik transaksi anda berlari bersama.

Sandi Fajariadi mempunyai pengalaman di product development terutama terkait payment, emoney dan ewallet. Di waktu senggang membuat aplikasi mobile seperti QRIS wantuno, cek RS dan dengan temannya bersenang senang membuat beberapa lagu di The Vader.

--

--

Sandi Fajariadi
Sandi Fajariadi

Written by Sandi Fajariadi

10+ years deep in payment systems, always curious about QRIS. Let's talk!

No responses yet