artikel 2

Ingin Sistem Onlinemu Jadi Favorit? Fokus pada Metrik Ini!

by with No Comment article

Baru-baru ini, warganet dibuat kesal dengan website e-materai. Saat ribuan warganet membutuhkan layanan e-materai, mereka malah mendapatkan notifikasi bug dan berbagai gangguan teknis lainnya. Pengalaman buruk ini sontak membuat warganet kecewa, bahkan sebagian tidak jadi menggunakan layanannya alias keluar begitu saja. 

Bisa dibilang, kondisi tadi adalah mimpi buruk bagi setiap pengembang atau desainer sistem online. Saat layanan tak berjalan sesuai harapan, pengguna akan merasa frustasi dan tanpa pikir panjang berpindah ke alternatif lain. Untuk itu, penting bagi pemilik bisnis untuk tidak hanya fokus pada pengembangan fitur, tetapi juga memastikan berbagai metrik penting juga terpenuhi saat membangun sistem. Apa saja metrik yang wajib diperhatikan? Yuk, mari kita pahami bersama.

Mengenal Availability, Reliability, Scalability, dan Security

Ketika membangun sebuah sistem online, ada empat metrik utama yang perlu diperhatikan: availability, reliability, scalability, dan security. Keempat metrik ini adalah fondasi dari sistem yang kuat dan handal. Berikut penjelasan lebih lanjut beserta contoh kasus untuk setiap metrik:

Availability

Availability mengacu pada seberapa sering dan seberapa lama sistem tersedia untuk digunakan oleh pengguna. Semakin tinggi availability, semakin kecil kemungkinan pengguna akan mengalami gangguan saat mengakses layanan Anda. 

Contoh kasus, ada sebuah platform e-commerce yang memiliki uptime 99,9%. Artinya, platform tadi tidak tersedia selama sekitar 8,76 jam dalam setahun. Namun, jika downtime muncul selama periode penjualan besar seperti Harbolnas, pemilik bisnis bisa mengalami kerugian pendapatan sangat besar, termasuk juga kehilangan kepercayaan pelanggan.

Reliability

Reliability merujuk seberapa konsisten dan bisa diandalkannya sistem dalam memberikan fungsi yang diinginkan. Sistem yang sering gagal atau error bisa menyebabkan pengguna kecewa. Ini berarti, pemilik bisnis akan kehilangan kepercayaan dari para penggunanya.

Contoh kasusnya, banyak pelanggan melakukan uninstall aplikasi perbankan mobile karena sering terjadi crash saat mereka bertransaksi. Meski availability aplikasi tinggi namun reliabilitas rendah, pengguna akan mulai mencari alternatif lain yang lebih stabil.

Scalability

Scalability adalah kemampuan sistem untuk menangani peningkatan beban atau jumlah pengguna tanpa penurunan kinerja. Di dunia digital yang terus berkembang, kemampuan sistem untuk tumbuh bersama dengan permintaan pengguna sangatlah penting.

Contoh kasus, pada saat peluncuran produk baru, sebuah startup teknologi mengalami lonjakan pengguna yang luar biasa. Namun, sistem mereka tidak dapat mengimbangi beban. Akibatnya, layanan jadi lambat dan seringkali gagal merespons. Atas kejadian itu, banyak pengguna meninggalkan platform tadi dan beralih ke kompetitor yang skalabilitas lebih oke. 

Security

Security adalah aspek yang tidak boleh diabaikan, terlebih jika sistem online kita menyimpan data-data pribadi pengguna. Ini mencakup segala upaya untuk melindungi sistem dan data pengguna dari ancaman dan serangan. Keamanan yang terabaikan dapat berakibat fatal, baik dari segi kerugian finansial maupun reputasi.

Misalnya, sebuah layanan penyimpanan cloud mengalami kebocoran data besar-besaran akibat serangan cyber. Data pribadi jutaan pengguna terekspos. Selain mengalami kerugian reputasi, perusahaan juga harus menghadapi tuntutan hukum dan biaya besar untuk memperbaiki kerentanan keamanan.

Pengukuran Metrik 

Untuk memastikan keempat metrik tadi terpenuhi, kita harus memahami bagaimana cara mengukurnya. Berikut beberapa komponen metrik yang dimaksud: 

  • Mengukur Availability

Uptime dan downtime adalah dua indikator utama. Idealnya, pemilik bisnis mengharapkan uptime mendekati 100%. Ini bisa diukur dengan menggunakan berbagai alat monitoring yang tersedia di pasaran, yang akan memberikan laporan mengenai seberapa sering dan seberapa lama sistem Anda aktif.

  • Mengukur Reliability

Mean Time Between Failures (MTBF) dan Mean Time To Repair (MTTR) adalah dua metrik yang sering digunakan. MTBF mengukur rata-rata waktu antara kegagalan sistem, sementara MTTR mengukur seberapa cepat sistem diperbaiki setelah mengalami kegagalan.

  • Mengukur Scalability

Untuk mengukur scalability, Anda perlu melihat kinerja sistem ketika beban meningkat. Langkahnya dilakukan melalui stress testing, yaitu mensimulasikan peningkatan jumlah pengguna atau data untuk melihat bagaimana sistem beradaptasi.

  • Mengukur Security

Ada banyak cara untuk mengukur keamanan. Misalnya, pengujian penetrasi (penetration testing) untuk menemukan kerentanan, ada juga audit keamanan secara berkala. Metrik lain yang dapat diperhatikan adalah frekuensi dan dampak dari insiden keamanan yang terjadi.

KESIMPULAN

Itu tadi beberapa metrik yang perlu kita perhatikan saat berniat mengembangkan sistem online. Tentu saja, memahami metrik-metrik tadi menjadi langkah awal yang penting. Namun, penerapannya dalam dunia nyata bisa jadi tantangan tersendiri. Lalu, bagaimana cara untuk menerapkan dan memaksimalkan metrik tersebut pada sistem online yang Anda kembangkan. Nantikan penjabaran detailnya di artikel berikutnya. 

Bahaya Race Condition, Bisa Sebabkan Kerugian Finansial Fatal

Bahaya Race Condition, Bisa Sebabkan Kerugian Finansial Fatal

by with No Comment article 
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.

  1. Buyer 1 lihat stok produk smart TV merek xyz ada 10
  2. Buyer 2 lihat stok produk smart TV merek xyz ada 10
  3. 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:

  1. Buyer 1 – server mengurangi stok produk smart TV merek xyz jadi 9
  2. Buyer 2 – server mengurangi stok produk smart TV merek xyz jadi 9
  3. 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:

  1. Korupsi data
  2. Inkonsistensi, dan
  3. 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