Pelajaran dari Rebuild Sistem Fintech: Dari Monolith ke Microservices

Mengapa sistem lama tidak bisa dipertahankan.

Sistem monolith lama perusahaan ini bukan sistem yang buruk — di masanya. Tapi ketika bisnis tumbuh, setiap perubahan kecil membutuhkan deploy ulang seluruh sistem. Risiko tinggi. Waktu tunggu panjang. Tim engineering tidak bisa bergerak cepat.

Masalah bisnis yang sesungguhnya bukan "sistem ini teknologinya ketinggalan zaman". Masalahnya adalah: time-to-market untuk fitur baru terlalu lambat, dan risiko downtime terlalu tinggi untuk bisnis fintech yang bergantung pada kepercayaan pengguna.

Keputusan paling penting: tidak rebuild dari nol.

Banyak vendor akan menyarankan "bangun ulang dari scratch". Lebih bersih, lebih modern, lebih mudah diestimasi.

Tapi itu keputusan yang salah untuk kasus ini. Sistem lama masih harus berjalan. Bisnis tidak bisa berhenti selama 6 bulan menunggu sistem baru.

Pendekatan yang kami ambil: strangler fig pattern — membangun service baru satu per satu, sambil sistem lama tetap berjalan, lalu secara bertahap memindahkan traffic ke service baru.

Pelajaran terpenting: scope control adalah segalanya.

Dengan 25 screens mobile dan 17 modul web, godaan terbesar adalah menambahkan fitur baru di tengah jalan. "Sekalian kita tambahkan X" adalah kalimat yang paling berbahaya dalam proyek seperti ini.

Kami membuat satu aturan sederhana: tidak ada fitur baru masuk sampai arsitektur dasarnya stabil. Feature freeze selama fase migrasi. Keputusan ini tidak populer di awal, tapi menjadi alasan mengapa proyek ini selesai tepat waktu.