Evolusi Arsitektur BackEnd di Blibli.com

Published in

Blibli.com Tech Blog

5 min readMay 3, 2018

Artikel ini saya terbitkan untuk teman-teman yang penasaran bagaimana sih evolusi arsitektur BackEnd nya di Blibli.com, dari awal Blibli.com berdiri, sampai saat ini.

Jika tertarik evolusi FrontEnd di Blibli.com, kalian bisa baca artikelnya yang di terbitkan oleh Irfan Maulana dengan judul Evolusi FrontEnd Developer di Blibli.com.

Blibli.com versi 1.0

Blibli.com bukanlah perusahaan StartUp seperti pada biasanya, dimana kebanyakan perusahaan StartUp, mereka berisikan founder-founder seorang programmer, dimana mereka build perusahaan StartUp sendiri. Blibli.com adalah anak perusahaan Djarum yang memang dibuat untuk menjadi perusahaan ECommerce.

Blibli.com pada awalnya mengejar rilis ke pasar secepatnya, sehingga untuk mempercepat proses rilis, Blibli.com tidak membuat sistem ECommerce-nya sendiri, melainkan membeli produk yang sudah jadi, dan juga men-outsource pembuatannya ke perusahaan Software House. Dan sudah bisa ditebak, awal Blibli.com adalah sebuah sistem ECommerce MONOLITH.

Scaling Tim

Permasalahan yang terjadi di semua perusahaan yang berbasis Produk seperti Blibli.com dan perusahaan yang lainnya adalah mengejar fitur. Yup, biasanya ini terjadi tarik menarik antara tim produk dan tim teknologi. Tim produk ingin menyajikan fitur secepatnya ke pasar, dan tim teknologi harus bisa mengimbangin kecepatan permintaan fitur tim bisnis.

Rata-rata orang awam terhadap teknologi, biasanya berpikir seperti ini, “Jika sebuah produk di kerjakan oleh 1 programmer dapat selesai dalam waktu 5 bulan, berarti jika menggunakan 5 programmer, produk tersebut bisa selesai dalam waktu 1 bulan”. Dan kenyataannya tidak seperti ini. Ada banyak faktor yang harus kita perhatikan.

Salah satu permasalahan sistem MONOLITH yang Blibli.com hadapi adalah; sistem MONOLITH tidak bisa mengikuti Scaling Tim yang dilakukan perusahaan. Semakin banyak Blibli.com menambah tim, ternyata tidak berbanding dengan kecepatan untuk memambahkan fitur pada sistem MONOLITH tersebut. Hal ini dikarenakan, semua programmer harus kerja di satu codebase yang sama, sehingga rawan konflik pekerjaan. Dan teknologi yang tidak terlalu familiar di produk MONOLITH tersebut juga menyebabkan programmer baru sulit untuk belajar.

Blibli.com versi 2.0, Era-nya Microservices

Zaman now, hampir semua StartUp migrasi besar-besaran dari MONOLITH ke MICROSERVICES. Bahkan saking HYPE-nya, StartUp yang baru munculpun langsung menggunakan arsitektur MICROSERVICES.

Blibli.com mulai rewrite semua sistem ke MICROSERVICES pada tahun 2014. Transisi ini dicetuskan oleh manager-manager dan senior-senior engineer di Blibli.com. Tujuan utama dari transisi ini adalah SCALING PRODUCT dan SCALING TEAM. Dengan menggunakan arsitektur MICROSERVICES, sekarang semua tim programmer memiliki codebase masing-masing sesuai dengan domain-nya, dan bisa fokus mengerjakan fitur yang berhubungan dengan produknya masing-masing tanpa harus bersinggungan dengan codebase tim lain. Dan yang paling penting, tiap tim sekarang bisa merilis fitur terbarunya ke pasar secara independen tanpa harus menunggu tim lain.

Masa Transisi ke MICROSERVICES

Blibli.com selesai me-rewrite semua sistem dari MONOLITH ke MICROSERVICES pada tahun 2016. Yup, cukup lama memang sekitar 2 tahun. Kenapa bisa lama sekali?

Hal yang paling sulit melakukan rewrite adalah, pada proses transisinya, dimana kita harus menjalankan 2 sistem bersamaan, yang MONOLITH dan yang MICROSERVICES. Dan selama 2 tahun tersebut, tidak mungkin kita menghentikan fitur di sistem lama, kita tetap harus mengembangkan fitur di sistem lama, sampai sistem baru benar-benar bisa mengejar semua fitur yang ada di sistem lama.

Blibli.com mulai membuat service-service sesuai dengan domain-nya masing-masing. Ada yang dibuat langsung independen, ada yang dibuat terintegrasi dengan sistem lama, ada juga yang hanya sebagai wrapper untuk sistem lama. Hal ini terus dilakukan sampai akhirnya sistem lama benar-benar tidak diperlukan lagi.

Pada masa transisi, jangan terlalu berharap dengan sistem yang ideal. Kadang kita punya ego bahwa saat me-rewrite sistem, semua harus menjadi ideal, kenyataannya tidak seperti itu. Ada kalanya bahkan kita harus membuat sistem baru yang menembak database sistem baru dan sistem lama secara bersamaan, padahal hal ini adalah hal yang sangat jijik keliatannya :D

API-First Development

Awal Blibli.com migrasi ke MICROSERVICES, konsep yang digunakan oleh Blibli.com hampir sama dengan semua perusahaan kebanyakan. Yaitu API-First Development. Dimana pada saat melakukan development sistem, setiap produk akan membuat API (biasanya menggunakan RESTful web service) untuk semua fitur yang dimiliki produk tersebut. Dan produk yang memutuhkan layanan dari produk tersebut, hanya butuh menembak API produk tersebut.

Tidak ada permasalahan dengan API-First Development, sampai pada akhirnya jika kita lihat secara melebar, akhirnya sistem pada MICROSERVICES tersebut akan terlalu bergantung dengan sistem lain. Hal ini agak menyulitkan akhirnya ketika sebuah sistem terlalu bergantung kepada sistem lain.

Yang paling sulit ketika menggunakan API-First Development adalah, saat sebuah service harus ngirim data ke beberapa service, jika pada suatu waktu ada service baru yang membutuhkan data tersebut, maka tim yang memegang service producer tersebut harus melakukan perubahan untuk menembak service yang baru.

Blibli.com versi 3.0, Event-First Development

Selain API-First Development, salah satu konsep MICROSERVICES yang populer adalah Event-First Development. Berbeda dengan API-First Development, pada Event-First Development, semua integrasi antar service menggunakan Event (via Message Broker). Hal ini mengakibatkan service tidak perlu lagi membuat API, melainkan service hanya perlu mem-publish Event ke Message Broker jika ingin membagikan datanya.

Pada akhir tahun 2017, dari Blibli.com melakukan inisiatif untuk menguji coba implementasi Event-First Development di Blibli.com. Dimulai dari sistem-sistem baru yang di develop, akhirnya setelah kurang lebih 3 bulan mengembangkan sistem baru, dan beberapa bulan menghadapi beberapa permasalahan yang terjadi di Event-First Development. Tim Blibli.com berhasil untuk mengimplementasikan konsep Event-First Development di Blibli.com

Tantangan dan permasalahan yang kita hadapi di Event-First Development nanti akan kita share di artikel berbeda.

Blibli.com versi 3, Event-First Development

Masa Transisi ke Event-First Development

Saat ini, kita sedang menjalani masa transisi dari API-First Development ke Event-First Development. Pastinya masa transisi ini akan berjalan lama, dimana sudah ratusan service yang sudah berjalan di production Blibli.com. Jadi saat ini proses migrasi yang kita lakukan diutamakan untuk service baru dan juga service yang perlu di improve.

Tertantang untuk berkolaborasi menjadi Backend Engineer di Blibli.com? Anda bisa hubungi saya Eko Kurniawan Khannedy via email eko.k.khannedy@gdn-commerce.com. Regards.

Referensi :