Belajar Software Architect - Evolution & Migration Architecture

#Pendahuluan

Setelah di episode 23 kalian membangun platform internal sebagai produk — golden paths, self-service infra, dan metrik DX — pada episode ini kita menghadapi pekerjaan yang menunggu di backlog sejak lama: engine pricing warisan dari sistem pertama Acme, ditulis sebelum modular monolith, kini menjadi modul paling lambat dirilis dan paling sering rusak saat flash sale.

Inilah realitas yang tidak dibahas cukup di literatur arsitektur: sistem production tidak punya tombol pause. Migration harus terjadi sambil traffic mengalir — seperti mengganti mesin pesawat di tengah penerbangan. Episode ini memberi toolkit untuk itu: strangler fig, expand-contract, anti-corruption layer, dan disiplin rencana migrasi yang selalu bisa mundur satu langkah.

#Mengapa Sistem Harus Terus Berevolusi

Arsitektur bukan keputusan sekali jadi — ia properti yang harus berevolusi bersama bisnis (evolutionary architecture). Tiga tekanan yang pasti datang:

• Bisnis berubah — model harga baru, pasar baru, regulasi baru (ep19) menuntut struktur baru.
• Hutang teknis berbunga — area yang tak tersentuh refactor makin mahal disentuh; biaya per rilis naik diam-diam.
• Teknologi bergeser — runtime EOL, dependency tanpa patch keamanan (ep19), model komputasi baru (ep17).

Pertanyaan architect bukan "migrasi atau tidak", tapi bagaimana bermigrasi tanpa membekukan bisnis dan tanpa big-bang rewrite — dua cara gagal klasik yang sama-sama terkenal.

#Strangler Fig Pattern

Nama pola ini dari pohon strangler fig yang tumbuh menyelimuti pohon tua sampai menggantikannya sepenuhnya. Mekaniknya:

Facade (API gateway atau reverse proxy) memegang kendali routing — setiap rute/kapabilitas dipindahkan satu per satu ke implementasi baru, sementara sisanya masih dilayani sistem lama. Pada titik tertentu, "pohon tua" tinggal cangkang kosong yang dimatikan tanpa upacara besar.

Tiga teknik pendukung yang membuat pola ini aman:

1. Parallel run / shadow traffic — rute baru menerima salinan trafik produksi; hasil kedua implementasi dibandingkan otomatis sebelum rute benar-benar dialihkan.
2. Routing berbasis persentase & flag — alihkan 1%, 10%, 50% dengan feature flag; rollback = ubah flag dalam hitungan detik.
3. Kill switch per rute — setiap rute yang dimigrasi bisa dikembalikan ke jalur lama tanpa deploy ulang.

#Expand-Contract untuk Skema Data

Mengubah schema database yang dipakai versi lama dan baru sekaligus butuh disiplin empat langkah — karena deploy kode dan migrasi data tidak bisa sinkron atomik:

1. EXPAND   : tambah kolom/tabel baru; tulis ganda (dual-write)
              versi lama + baru
2. BACKFILL : isi data historis ke struktur baru, batch,
              terverifikasi checksum
3. CONTRACT : alihkan baca-tulis utama ke struktur baru;
              lama tetap ada sebagai fallback
4. CLEANUP  : hapus dual-write dan struktur lama setelah
              masa pengamatan stabil

Aturan besinya: jangan pernah menghapus apa pun di langkah sebelum verifikasi penuh, dan setiap langkah punya rollback sendiri. Langkah cleanup yang dilakukan seminggu terlalu dini adalah cerita horor klasik migrasi data.

#Anti-Corruption Layer

Sistem legacy jarang punya model domain yang sehat — nama field menyesatkan, logika tersebar, konsep campur aduk. Jika sistem baru mengimpor model legacy mentah-mentah, racun itu menyebar ke desain baru Anda.

Anti-corruption layer (ACL) — dari Domain-Driven Design (ep4) — adalah lapisan penerjemah: sistem baru bekerja dengan model bersih miliknya, ACL menerjemahkan bolak-balik ke format legacy. Untuk studi kasus kita: engine pricing baru bicara PriceRule, DiscountPolicy; ACL menerjemahkan dari struktur PRC_CALC_V2 legacy. Saat legacy mati nanti, ACL ikut dibuang — dan model bersih kita tidak pernah terkontaminasi.

#Rencana Migrasi yang Sehat

Migration plan profesional punya bentuk yang konsisten:

• Inventaris & peta dependensi — semua pemanggil engine pricing, semua tabel yang disentuh, semua job background; tanpa ini, "satu per satu" hanya slogan.
• Urutan berbasis nilai-risiko — mulai dari rute read-only atau low-risk untuk memvalidasi mekanik, nilai cepat untuk membangun momentum politik.
• Metrik sukses per fase — parity rate shadow run, latency budget, error rate; angka, bukan perasaan.
• Rollback eksplisit per fase — "kalau gagal, apa satu perintah untuk mundur?" Jika jawabannya butuh rapat, rencananya belum selesai.
• Komunikasi berkala — stakeholder harus tahu posisi: fase berapa, metrik apa, keputusan go/no-go kapan.

#Praktik: Migration Plan Studi Kasus

Mari ratifikasi rencana modernisasi pricing Acme:

scope: engine pricing legacy -> modul pricing modern
strategi: strangler fig via gateway, tanpa freeze rilis
fase_0_inventaris:
  - pemetaan 34 pemanggil (api, job, admin tool)
  - tabel legacy: PRC_RULES, PRC_CALC_LOG (audit ep19)
fase_1_fondasi:
  - facade routing di api-gateway, flag per rute
  - ACL: model PriceRule <-> PRC_CALC_V2
  - observability: parity dashboard shadow run
fase_2_shadow_run:
  - salin trafik read ke engine baru, bandingkan hasil
  - target: parity >= 99.9% selama 2 minggu
  - divergensi dicatat sebagai test case baru
fase_3_alih_bertahap:
  - rute internal dulu (admin), lalu checkout
  - persentase 1% -> 10% -> 50% -> 100%, hold per tahap
  - rollback: flip flag, tanpa deploy ulang
fase_4_data:
  - expand-contract tabel rule; backfill batch checksum
  - reconciliation job tiap jam selama transisi
fase_5_retirement:
  - engine lama read-only 30 hari, lalu dimatikan
  - ACL dibuang; ADR superseded dirapikan (ep6)
metrik_per_fase: [parity_rate, latency_p95, error_rate]
rollback_rule: setiap fase wajib punya 1 perintah mundur

Perhatikan fase_2: target parity 99.9% selama dua minggu adalah contoh metrik sukses yang bisa difalsifikasi — konsisten dengan disiplin skenario episode 22. Dan rollback_rule memaksa jawaban konkret untuk pertanyaan yang sering ditunda sampai terlambat.

#Kesalahan Umum

• Big-bang rewrite — freeze logika lama, bangun semua dari nol; dua sistem hidup berdampingan berbulan-bulan dan deadline tunggal yang runtuh di ujung.
• Dual-write tanpa reconciliation — divergensi data senyap antara lama dan baru, ditemukan berbulan-bulan kemudian saat audit atau keluhan pelanggan.
• Cleanup terlalu dini — menghapus struktur/jalur lama sebelum masa pengamatan habis; rollback jadi mustahil tepat saat dibutuhkan.
• Tanpa ACL — model legacy bocor ke sistem baru; hutang desain lama bereinkarnasi di codebase yang katanya modern.
• Alih trafik tanpa shadow run — parity dicek langsung di produksi menggunakan pelanggan sebagai test harness.
• Rencana tanpa rollback per fase — "mundur" berarti proyek darurat lintas tim; migrasi kehilangan kredibilitas di insiden pertama.

#Penutup

Inti yang harus dibawa pulang:

• Arsitektur adalah properti yang berevolusi: pertanyaannya bukan apakah migrasi perlu, tapi bagaimana melakukannya sambil traffic mengalir — tanpa big-bang, tanpa freeze.
• Strangler fig mengganti sistem lewat facade routing, rute demi rute; didukung parallel run/shadow traffic, flag persentase, dan kill switch per rute.
• Expand-contract menjadwalkan perubahan skema dalam empat langkah dengan rollback di tiap langkah; dual-write selalu berpasangan dengan reconciliation.
• Anti-corruption layer menjaga model domain baru tetap bersih dari semantik legacy — dan mati bersama legacy saat waktunya tiba.
• Studi kasus kini punya migration plan enam fase untuk engine pricing: inventaris, fondasi ACL, shadow run dengan target parity, alih bertahap, expand-contract data, hingga retirement — semuanya dengan aturan rollback satu perintah.

Di episode 25 selanjutnya kita beralih dari artefak ke manusia: architecture leadership — bagaimana architect memimpin tanpa otoritas formal, menulis technical vision yang diikuti, mengambil keputusan one-way vs two-way door, dan menumbuhkan architect berikutnya. Sampai jumpa!