Sudah 2 hari dari hari ini transaksi gue yang menggunakan Paypal gagal. Gue kira ada kekurangan saldo (problem utama transaksi) yang meskipun saldo gue… lebih dari cukup. Lalu gue coba menambahkan saldo lagi menjadi… 3x lipat dari saldo pada saat itu?
Dan ternyata masih gagal.
Mungkin kendala di penerimaan OTP via SMS, dan gue mengisi kembali pulsa sekalipun pulsa sekarang lebih dari cukup sekalipun untuk menerima 666 OTP.
Dan ternyata masih gagal.
Insting sebagai programmer gue mulai bermain: cek devtools. Dari payload yang ada, tidak ada yang penting selain error code NO_VALID_FUNDING_INSTRUMENT yang of course hanya orang-orang di industri tersebut yang tau. Bahkan tidak ada pesan apapun di UI Paypal terkait mengapa transaksi gue gagal.
Melihat riwayat transaksi di Paypal, transaksi terakhir yang berhasil adalah dari Linode di awal Desember 2022 kemarin.
Mungkin kendala dari penerbit kartunya?
Transaksi terakhir yang tidak menggunakan Paypal hanya berjarak 12 hari dan bahkan lebih baru, transaksi tersebut ke Replit yang mana menggunakan Stripe.
Sebagaimana solusi favorit dari ISP kesayangan warga Indonesia, gue mencoba untuk mendaftarkan ulang kartu debit tersebut. Setidaknya di Paypal gue ada MasterCard dan Visa yang diterbitkan oleh dua bank berbeda. Ketika mencoba mendaftarkan ulang salah satu kartu tersebut, yang MasterCard gagal dan tentu saja tidak ada pesan intuitif yang bisa dipahami pengguna akhir terkait kegagalan tersebut.
Lalu gue baru inget kalau memang tidak ada dana di kartu yang Visa dan menggunakan yang MasterCard sebagai preferred card. Setelah coba mengisi saldo ke yang Visa, transaksi berhasil. Something’s wrong dengan yang di MasterCard.
Setelah menghubungi support dari penerbit kartu tersebut, ternyata memang ada kendala terkait transaksi dengan merchant yang belum mendukung 3DS, dan Paypal salah satunya, meskipun ini agak fishy. Ketika meminta kepastian kapan kendala tersebut selesai dan dimana gue bisa mengikuti kabar kalau problem tersebut sudah terselesaikan, tidak ada balasan lain yang intinya “jika nanti sudah bisa, berarti sudah bisa, kak”.
Single Point Of Failure (SPOF)
Dalam infrastruktur, SPOF adalah hal umum yang sering dihadapi. Sebagai tambahan, ada perbedaan tipis antara “fault” dan “failure”, dan in fact, username internet gue “faultable(s)” terilhami dari dua hal tersebut. Fault adalah tentang “ketika 1 unit gagal melakukan pekerjaannya” dan failure adalah tentang ketika si fault tersebut menyebabkan seluruh sistem tidak berguna.
Gampangnya, dalam aplikasi web, misal, sebuah aplikasi gagal mengunggah/menampilkan foto dari pengguna. Itu adalah sebuah fault, dan tidak menyebabkan seluruh sistem tidak berguna. Pengguna masih bisa menggunakan aplikasi tersebut, meskipun tidak ada gambar yang bisa dimuat.
Contoh fauliure nya adalah misal aplikasi tersebut tidak bisa terhubung ke basis data. Sistem akan menjadi tidak berguna, karena, well, aplikasi hanyalah penghubung untuk menampilkan data yang disimpan di basis data, dan sekarang basis data tersebut tidak dapat diakses.
Dalam keseharian, kita tidak luput dari SPOF. Misal, jika hidup hanya bergantung dengan gaji, apa yang akan terjadi bila pada saat tertentu, tidak menerima gaji? Atau, kita bergantung dengan listrik. Apa yang terjadi bila pada suatu waktu listrik sedang mati?
SPOF adalah hal yang tidak bisa dihindari, dan satu-satunya cara untuk menghadapinya adalah dengan memiliki “backup plan”. Misal, seperti memiliiki tabungan. Atau, memiliki “pembangkit listrik” sendiri.
Atau, memiliki 2 kartu yang diterbitkan oleh 2 bank berbeda.
Pertanyaannya, berapa angka yang tepat untuk strategi “backup plan” tersebut? Tentu jawabannya tergantung, tapi kita memiliki formula.
Redundancy
Dalam sistem penyimpanan, ada sebuah teknologi bernama “RAID” alias “Redundant Array of Inexpensive Disks”. RAID adalah sebuah rancangan dimana penyimpanan disebar ke “susunan” penyimpanan yang ada.
Yang paling mudah adalah RAID 0, ini adalah tentang striping. Gampangnya, ketika menyimpan 1 berkas berukuran 1 MB, setiap penyimpanan masing-masing menyimpan 0.5 MB. Tapi ini solusi lain untuk masalah lain.
Sekarang yang cukup populer adalah RAID 1, ini adalah tentang mirroring. Gampangnya, ketika menyimpan 1 berkas berukuran 1 MB, setiap penyimpanan masing-masing menyimpan berkas tersebut. Jika 1 penyimpanan terjadi kegagalan, maka bisa menggunakan penyimpanan lainnya.
Kita belum mendapatkan angka yang tepat, tapi mari kita ambil contoh “praktik terbaik” dalam membuat backup.
Dalam melakukan backup, ada sebuah strategi bernama 3-2-1. Gampangnya, setidaknya lo harus punya 3 salinan data, yang mana 2 nya berada di penyimpanan lokal tapi di perangkat berbeda, dan 1 nya berada di penyimpanan eksternal.
Teknik ini sudah lama gue gunakan:
- Singkronisasi direktori X ke perangkat lain (server linux di rumah) via Syncthing
- Singkronisasi direktori X tersebut ke iCloud Drive (E2EE manual via gocryptfs)
- Salin direktori X tersebut ke SSD eksternal
Ini adalah redundancy alias mubazir: gue memiliki 3 barang yang exactly sama di tempat berbeda-beda, dan sampai hari ini masih dianggap mubazir karena tidak ada kasus yang membuat duplikasi tersebut berguna, yang berarti kabar baik.
SPOF adalah tentang 1 poin yang bila poin tersebut terjadi kegagalan, menyebabkan keseluruhan sistem gagal. Jika laptop adalah satu-satunya media untuk lo bekerja, imagine if someday laptop lo… gak bisa nyala. Atau, terdapat kesalahan di SSD.
Semua orang tidak ingin berhadapan dengan kegagalan, tapi memiliki backup plan (atau gue pribadi menyebutnya “just in case” plan) adalah satu-satunya cara untuk bersiap jika kegagalan tersebut terjadi.
Preventing the unpreventable
Kembali ke 3-4 bulan yang lalu, kemarin-kemarin tempat kerja gue cukup sibuk untuk mendapatkan sertifikasi. Salah satu kepatuhan yang harus dipenuhi dalam mendapatkan sertifikasi tersebut adalah tentang “pemulihan bencana” alias Disaster Discovery. Tidak ada yang menginginkan bencana terjadi, tapi kita harus memiliki rencana ketika bencana tersebut terjadi.
Rancangan kita adalah dengan menjalankan setiap aplikasi di 3 zona berbeda (Availability Zone) meskipun di satu region, alias multi-zone, karena memang belum ada kebutuhan untuk multi-region.
Kasusnya, jika zona a terjadi pemadaman, setidaknya masih ada zona b dan zona c. Semua penyimpanan persisten memiliki klon, as always, untuk kasus “just in case”.
Ini hal yang mubazir dan memakan 3x cost. Bagian menariknya, kita selalu berharap agar kemubaziran tersebut tetap mubazir, means, nothing is wrong.
Dan jika suatu saat terjadi, kita sudah memiliki rencana. Of course kerugian tidak bisa dihindari, namun setidaknya, tidak akan ‘serugi’ itu—ingat tentang kemubaziran yang tadi sempat disinggung?
Penutup
Sampai hari ini gue menggunakan 2 bank dan 4 rekening: BCA dan Jenius (BTPN). Sempat kepikiran untuk menutup rekening Jenius, tapi selalu gue urungkan karena pertanyaan “gimana kalau yang BCA gue lagi ga bisa dipakai?” sekalipun gue selalu menghindari menggunakan Jenius sebagaimana warga internet—yang mengenal gue—tau.
Tidak pernah kepikiran ketika pertama kali menggunakan BCA bahwa kasus di awal tulisan ini bakal terjadi, dan gue sempat melupakan bahwa masalah adalah sesuatu yang tidak bisa dihindari, sekalipun untuk “top-class” ataupun “well-known” company.
Khususnya ke masalah yang tidak bisa gue kontol (typo yang disengaja) seperti kegagalan transaksi di Paypal tersebut yang membuat salah satu website gue tidak bisa diakses padahal sedang butuh-butuhnya.
Sebagai penutup, pertimbangkan membuat “just in case” plan jika memang belum. Entah backup atau asuransi, yang penting jika menyebabkan kerugian, setidaknya tidak serugi itu.
Membayar feesible 10rb/bulan, membeli token listrik 2x lebih banyak dari pemakaian umum, membeli kebutuhan pokok 2x lebih banyak, memiliki simpanan 2x lebih besar dari gaji bulanan, dan menyimpan data yang sama 2x di tempat berbeda bukanlah sebuah masalah.
Dan gue hanya sedang meyakinkan kembali diri gue.