Sebelum masuk ke tahun 2017 atau era microservice di Tiket, sebenarnya waktu itu gw sudah merancang microservice terlebih dahulu pada akhir 2016. Payment di Tiket, response timenya sungguh sangat jelek pada masa itu terutama dalam hal menerima callback dari third party. Jadi kalau ada payment gateway yang memberikan request pada jam sibuk, sistem Tiket akan memberikan response sekitar 6-7 detik bahkan bisa lebih dari itu. Hal ini sangat menjengkelkan karena gw sering banget mendapatkan info di grup yang menanyakan mengenai, “Apakah Tiket sedang down?”. Oleh karena itu gw berpikir untuk membuat sebuah sistem kecil untuk menerima callback dari third party sehingga inquiry atau notification payment selalu Tiket terima lebih dahulu dan seandainya Tiket beneran down, kami hanya tinggal mengembalikan dana saja. Pada masa itu gw menyebut sistem ini dengan nama IPAAS (Intelligent Payment As A Service), keren gak tuh namanya? LOL.
Sebelum mengimplementasikan ke Tiket, gw pun harus melakukan presentasi ke Ko Nat terlebih dahulu. Beliau pun merasa apa yang gw ingin kerjakan sudah sesuai dengan kemauan beliau, karena ini merupakan langkah pertama untuk memecah monolith Tiket menjadi microservice. Kami pun berdiskusi untuk tahap implementasi coding dengan melakukan pemilihan framework terlebih dahulu. Pada masa itu Golang dan Java belum jadi pilihan karena belum ada yang bisa ngoding pake bahasa pemrograman tersebut sehingga pilihannya waktu itu adalah menggunakan PHP lagi namun menggunakan Phalcon. Awalnya gw lebih memilih menggunakan laravel waktu itu (lebih tepatnya lumen) karena menurut gw sudah saatnya menggunakan framework PHP yang lebih baik dari Code Igniter dan juga komunitasnya sangat hidup. Sayangnya Ko Nat berpikiran lain dan menunjukkan bahwa secara performance laravel merupakan framework yang paling buruk (pada masa itu) ketimbang framework PHP yang lain (bahkan masih dibawah CI). Website yang digunakan mengetes adalah ini.
Untuk tech stack yang digunakan pada saat itu adalah sebagai berikut.
- PHP menggunakan Phalcon sebagai framework.
- MySQL Percona.
- Memcache.
Mungkin banyak yang tanya, kenapa menggunakan Memcache dan bukan Redis? Lagi-lagi ini adalah saran dari Ko Nat, karena menurut beliau (waktu itu dia kasi data juga), bahwa Memcache jauh lebih cepat dan lebih mudah dimaintain ketimbang menggunakan Redis. Karena waktu itu gw kurang paham, jadi gw iya-iya saja. Kalau sekarang, pertanyaannya gw bukan kenapa Memcache dan bukan Redis, melainkan kenapa harus pake Cache #eaa. Tidak hanya tech stack, Pak Faren selaku Dev Manager saat itu juga menambahkan requirement tambahan yakni menggunakan unit test. Pada zaman Jahiliyah, semua koding yang naik di production, hanya di test oleh engineer dan juga QA. Test nya pun bersifat manual dan bukan per unit. Jadi requirement ini adalah salah satu yang harus dikerjakan gw saat itu. Setelah semua selesai maka fase koding pun dimulai. Untuk design systemnya sebagai berikut.
3 Flow yang digambarkan diatas merupakan flow standard yang digunakan untuk metode pembayaran Jatis, hanya saja flow ini dijadikan acuan untuk semua metode pembayaran kedepannya karena gw menganggap ini yang paling general. Hampir semua payment pasti memiliki flow berikut:
- Inquiry Payment.
Third party akan bertanya ke server merchant mengenai jumlah transaksi yang harus dibayar oleh customer via payment gateway. - Confirm Payment / Notification Payment.
Third party akan mengirimkan signal ke server merchant apabila uang berhasil di debit sehingga merchant dapat melanjutkan proses pemesanan. - Payment Checker.
Payment gateway memiliki fasilitas untuk melakukan inquiry ulang buat merchant untuk mengecek apakah transaksi sebelumnya beneran berhasil apa tidak.
Proses pengerjaan pun dimulai dari metode pembayaran yang memiliki risk paling kecil yakni Rintis (pembayaran yang hanya bisa melalui ATM BCA). Gw pun melakukan pengetesan dengan bantuan infra dan QA yakni menggunakan sejenis canary (jadi order id khusus yang dibelokkan trafficnya ke microservice) dan QA melakukan transaksi langsung ke ATM BCA dan hasilnya berhasil dengan baik. Gw pun semakin pede bahwa ini akan menjadi microservice pertama yang akan lahir di Tiket. Ko Nat cukup happy dengan hasilnya dan meminta gw segera mengerjakan ke metode pembayaran yang lebih besar yakni virtual account nicepay.
Yang disayangkan dalam project ini adalah gw gagal membuat unit test karena waktu itu belum tahu caranya mocking dan melakukan test per service (gw menyebutnya dulu logic). Hal yang paling gw benci dalam menggunakan phalcon adalah lemahnya komunitas yang membantu ketika kita mengalami kesulitan. Gw pun sudah googling sana sini dan juga bertanya langsung ke komunitas phalcon di website resminya dan tidak ada yang menjawab, sungguh membagongkan sekali. Pada akhirnya, unit test tidak berhasil dikerjakan.
Gw lupa alasannya karena apa, hanya saja project ini tidak pernah direlease ke production karena satu dan lain hal. Tetapi Pak Handaru melihat potensi dari microservice yang telah gw buat dan memasukkannya ke dalam grand design microservice Tiket yang akan kami kerjakan pada tahun 2017. Pada masa itu, hampir setiap hari, Ko Nat, Mas Ferdi, Pak Faren, Pak Aji dan juga Pak Handaru meeting setiap malam selama kurang lebih 2 minggu untuk membahas apa yang akan dikerjakan oleh tim tech pada tahun 2017. Di bulan Desember tahun 2016, kami pun diminta untuk mempresentasikan microservice yang ada di dalam benak kami ke seluruh tim tech. Waktu itu gw malah kebagian merancang microservice finance dan bukan payment LOL. Yang kebagian waktu itu malah si Deni yang megang tim hotel LOL. Untuk grand design microservice yang dibuat waktu itu diberi nama The Port.
Untuk cerita berikutnya gw akan bercerita mengenai bagaimana requirement The Port mulai dari grand design, tech stack yang digunakan, infrastruktur aplikasi, jumlah resource, juga continuous integration dan continuous delivery.