Tampilan
Rekomendasi Strategi Migrasi
Bagian ini adalah deliverable utama terkait pertanyaan: apakah improvement & migrasi stack sebaiknya lanjut dari repo yang sama atau bikin from scratch dengan mengacu workflow codebase ini?
TL;DR — Rekomendasi
Rekomendasi
Lanjutkan dari repo yang sama dengan pendekatan migrasi incremental (strangler-fig), BUKAN rewrite from scratch (big-bang).
Alasan inti: sistem ini sudah production dan melayani banyak paid customer, dengan integrasi eksternal yang dalam dan sarat edge case (Zimbra SOAP mirror ganda, ZoneMTA, Zoho Books, Xendit recurring, pipeline Elasticsearch, SparkPost). Rewrite penuh berisiko sangat tinggi terhadap kontinuitas pendapatan dan layanan, sementara sebagian besar nilai bisnis justru terletak pada logika integrasi yang sudah "battle-tested" tersebut.
Mengapa bukan rewrite from scratch?
Rewrite penuh terhadap sistem billing + email + production punya rasio risiko/imbalan yang buruk:
| Risiko rewrite | Penjelasan pada konteks ATE |
|---|---|
| Kehilangan edge case tersembunyi | Logika Zimbra mirror ganda, penanganan callback Xendit recurring, strategi parsing log ES — banyak aturan implisit yang tidak terdokumentasi. Rewrite cenderung mengulang bug yang sudah diperbaiki bertahun-tahun. |
| Risiko pendapatan | Bug di alur billing/pembayaran berdampak langsung ke revenue & kepercayaan paid customer. |
| Dual-running mahal | Menjalankan sistem lama & baru paralel untuk billing real-money sangat kompleks (rekonsiliasi pembayaran, idempotensi webhook). |
| Waktu tanpa nilai | Rewrite besar bisa berbulan-bulan tanpa fitur baru; kompetitor & kebutuhan customer tetap jalan. |
| Ketergantungan pengetahuan | Pengetahuan domain ada di kode + tim saat ini; rewrite paralel menyedot kapasitas tim yang sama. |
Rewrite from scratch baru masuk akal jika: arsitektur lama benar-benar buntu (tidak bisa diupgrade), atau ada perubahan fundamental model bisnis. Kondisi ATE tidak demikian — stack-nya konvensional (Node/Express/Sequelize/PostgreSQL) dan sepenuhnya bisa dimodernisasi secara bertahap.
Mengapa incremental (strangler-fig)?
Pola strangler-fig: bangun kapabilitas baru di sekeliling sistem lama, ganti bagian per bagian, sampai sistem lama "tercekik" dan bisa dipensiunkan — tanpa pernah ada momen big-bang.
Keuntungan:
- Selalu shippable — tiap langkah kecil bisa dirilis & di-rollback.
- Risiko terisolasi — kegagalan terbatas pada satu modul.
- Nilai berkelanjutan — fitur & perbaikan tetap jalan selama migrasi.
- Reuse aset — workflow, skema DB, dan integrasi yang sudah ada dipakai ulang.
Perbandingan opsi
| Aspek | Lanjut repo (incremental) ✅ | Rewrite from scratch ❌ |
|---|---|---|
| Risiko terhadap production | Rendah–sedang (terisolasi) | Tinggi (big-bang) |
| Time-to-value | Cepat & kontinu | Lambat (berbulan-bulan) |
| Reuse logika integrasi | Maksimal | Minim (tulis ulang) |
| Risiko billing/revenue | Terkontrol | Tinggi |
| Beban tim | Tersebar bertahap | Berat & paralel |
| Kebersihan akhir | Baik (jika disiplin) | Sangat baik (jika berhasil) |
| Kapan dipilih | Kondisi ATE saat ini | Hanya jika arsitektur buntu total |
Posisi "from scratch" yang tetap sehat
Jika tim sangat ingin basis kode baru yang bersih, lakukan dalam kerangka strangler, bukan big-bang:
- Buat repo/service baru untuk modul greenfield (mis. service pengiriman/relay baru, atau service reporting), yang berjalan berdampingan dengan monolith lama di belakang gateway.
- Gunakan dokumentasi & workflow di situs ini sebagai spesifikasi untuk modul baru tersebut.
- Pindahkan trafik per endpoint/modul secara bertahap, bukan sekaligus.
Dengan cara ini, "mengacu pada workflow yang ada di codebase ini" tetap terpenuhi tanpa menanggung risiko big-bang.
Prinsip yang harus dipegang selama migrasi
- Production first — jangan pernah mengorbankan kontinuitas layanan demi kebersihan kode.
- Backup & reversibility — setiap perubahan DB harus reversible dan didahului backup.
- Idempotensi webhook — pastikan callback Xendit/SparkPost aman diproses berulang.
- Observability dulu — tambahkan logging/metrics/alerting sebelum mengubah perilaku.
- Test sebelum refactor — bangun jaring pengaman (characterization tests) di area kritikal (billing, kuota, callback) sebelum menyentuhnya.
- Satu perubahan satu rilis — hindari menggabungkan banyak perubahan besar dalam satu deploy.
Langkah konkret per fase ada di Roadmap Migrasi.