Memilih runtime backend sering terasa seperti keputusan teknis besar, padahal pertanyaan utamanya bukan sekadar “mana yang lebih cepat”, melainkan masalah apa yang benar-benar sedang diselesaikan. Rewrite ke runtime atau bahasa lain kadang masuk akal, tetapi lebih sering organisasi mendapatkan hasil lebih baik dari profiling, refactor terarah, perbaikan arsitektur, atau pemecahan komponen yang terlalu gemuk.

Jika pertanyaan Anda adalah kapan rewrite layak dilakukan, jawabannya: rewrite baru layak ketika hambatan utamanya memang berasal dari batas fundamental runtime, model konkurensi, karakteristik memori, atau biaya maintainability yang tidak realistis diperbaiki secara bertahap. Jika bottleneck masih ada di query database, desain API, pola I/O, atau boundary modul yang buruk, rewrite biasanya hanya memindahkan masalah ke stack baru dengan biaya lebih mahal.

Masalah yang Sering Salah Diagnosa

Banyak tim menganggap runtime backend sebagai akar masalah karena gejalanya terlihat di CPU tinggi, latency membesar, atau memory usage naik. Padahal, dalam praktik, sumber masalah sering ada di lapisan lain:

  • Query database tidak efisien: N+1 query, index buruk, lock contention.
  • I/O blocking: pemanggilan service eksternal lambat, retry tidak terkendali, timeout terlalu panjang.
  • Arsitektur aplikasi terlalu padat: semua tanggung jawab berada di satu proses tanpa boundary yang jelas.
  • Object lifecycle tidak terkontrol: cache berlebihan, serialisasi mahal, buffer menumpuk.
  • Tool observability lemah: tim tidak tahu bottleneck sebenarnya sehingga runtime disalahkan.

Ini sebabnya rewrite sering gagal memenuhi ekspektasi. Ketika akar masalahnya adalah desain sistem, mengganti JavaScript ke Rust, Go, Java, atau bahasa lain belum tentu memperbaiki throughput secara signifikan. Kadang justru kompleksitas naik karena tim kehilangan produktivitas, tooling, dan kecepatan iterasi.

Memilih Runtime Backend: Faktor yang Perlu Dinilai

Saat memilih runtime backend, jangan mulai dari benchmark mentah. Mulailah dari karakter beban kerja dan kebutuhan operasional.

1. Profil beban kerja: CPU-bound vs I/O-bound

Jika mayoritas request menunggu database, storage, atau HTTP downstream, runtime yang sangat cepat di level CPU belum tentu memberi dampak besar. Sebaliknya, jika aplikasi banyak melakukan parsing, kompresi, enkripsi, transformasi data, atau komputasi berat per request, pilihan runtime lebih berpengaruh.

  • I/O-bound: fokus pada connection pooling, timeout, retry policy, backpressure, dan efisiensi async.
  • CPU-bound: fokus pada efisiensi memori, paralelisme, native code path, dan profiling hotspot.

2. Stabilitas dan kematangan ekosistem

Runtime yang cepat tetapi tooling observability, debugging, dan deployment-nya belum matang bisa menjadi beban. Backend produksi membutuhkan lebih dari sekadar performa mentah:

  • logging dan tracing yang mudah diintegrasikan,
  • dukungan library untuk database, queue, auth, dan HTTP,
  • kemudahan menulis test integrasi,
  • dukungan operasional saat incident.

Tim sering meremehkan biaya dari ekosistem yang belum mapan. Keuntungan performa bisa habis karena waktu debugging lebih lama dan dependency yang lebih rapuh.

3. Hiring dan distribusi keahlian tim

Stack backend tidak hidup di ruang kosong. Jika hanya satu atau dua engineer benar-benar menguasai runtime baru, organisasi menciptakan bus factor yang berbahaya. Bahasa atau runtime yang lebih aman secara desain bisa tetap menjadi keputusan buruk bila terlalu sulit direkrut, di-onboard, atau dipelihara oleh tim yang ada.

4. Debugability dan operability

Salah satu trade-off paling penting tetapi sering diabaikan adalah kemudahan memahami sistem saat rusak. Runtime yang performanya tinggi tetapi sulit di-debug saat deadlock, leak, race condition, atau panic akan meningkatkan MTTR (mean time to recovery).

Pertanyaan praktis yang perlu dijawab:

  • Seberapa mudah mendapatkan stack trace yang berguna?
  • Bisakah kita mengambil heap/profile di produksi dengan aman?
  • Apakah tracing async mudah dibaca?
  • Apakah engineer on-call nyaman mendiagnosis masalah di stack ini?

5. Maintainability jangka panjang

Maintainability bukan hanya soal sintaks bahasa, tetapi juga soal boundary modul, kontrak antarkomponen, disiplin testing, dan kompleksitas build/deploy. Runtime yang lebih cepat namun memaksa banyak kode unsafe, FFI yang rumit, atau alur build yang kompleks bisa meningkatkan biaya perubahan di masa depan.

Rewrite Besar vs Optimasi Bertahap

Kapan optimasi bertahap lebih masuk akal

Optimasi bertahap hampir selalu pilihan awal yang lebih rasional jika sistem masih bisa diobservasi dan diubah tanpa mematahkan bisnis. Pendekatan ini cocok bila:

  • bottleneck sudah bisa diisolasi ke endpoint, query, atau komponen tertentu,
  • SLA belum gagal total,
  • tim masih bisa merilis perbaikan kecil dengan aman,
  • masalah utama ada di desain aplikasi, bukan batas runtime.

Contoh langkah yang sering memberi hasil nyata tanpa rewrite:

  1. Tambah tracing per request dan profile CPU/memory.
  2. Perbaiki query dan indexing.
  3. Kurangi serialisasi/deserialisasi yang tidak perlu.
  4. Pindahkan pekerjaan berat ke queue atau worker terpisah.
  5. Tambahkan cache dengan invalidasi yang jelas.
  6. Ekstrak hotspot ke service kecil atau library native jika benar-benar perlu.

Keunggulan pendekatan ini adalah risiko lebih rendah, umpan balik lebih cepat, dan pengetahuan domain tetap berada di codebase yang sudah ada.

Kapan rewrite besar mulai layak dipertimbangkan

Rewrite layak dipertimbangkan jika beberapa kondisi berikut benar secara bersamaan:

  • Ada batas struktural yang sulit diatasi, misalnya model konkurensi atau konsumsi memori runtime memang tidak cocok untuk workload inti.
  • Masalah utama sudah terbukti lewat profiling, bukan asumsi atau opini.
  • Biaya patching terus-menerus sudah lebih mahal daripada membangun ulang bagian inti.
  • Boundary domain cukup jelas, sehingga sistem bisa ditulis ulang bertahap, bukan big bang migration.
  • Tim punya kompetensi dan runway operasional untuk membangun, menguji, dan menjalankan dua stack selama masa transisi.

Rewrite yang sehat biasanya tidak dimulai dari “kita pindah semuanya”, melainkan dari satu target yang jelas: komponen HTTP parser, worker komputasi berat, pipeline data, atau service tertentu yang memang dominan terhadap biaya dan latency.

Gejala yang Benar-Benar Mengarah ke Rewrite

Berikut sinyal yang lebih kuat bahwa rewrite mungkin perlu dipertimbangkan:

1. Hotspot performa berada di lapisan runtime, bukan aplikasi

Misalnya setelah query database, cache, batching, dan arsitektur I/O diperbaiki, CPU tetap habis di parsing, allocation, garbage collection, atau overhead abstraksi runtime. Ini sinyal lebih valid daripada sekadar “bahasa X lebih cepat dari bahasa Y”.

2. Kebutuhan resource tidak ekonomis di skala sekarang

Jika untuk memenuhi traffic tertentu Anda harus menambah instance jauh lebih banyak daripada nilai bisnisnya, dan profiling menunjukkan overhead runtime sebagai penyebab utama, rewrite sebagian bisa memberi ROI yang masuk akal.

3. Constraint keamanan atau isolasi tidak bisa dipenuhi dengan baik

Pada beberapa jenis workload, kebutuhan memory safety, kontrol resource, atau isolasi modul dapat membuat runtime tertentu kurang cocok. Namun ini tetap harus dibuktikan pada kebutuhan nyata, bukan sekadar preferensi teknologi.

4. Kode inti terlalu sulit dipelihara karena fondasi awal keliru

Jika codebase dibangun di atas asumsi yang salah—misalnya semua alur sinkron, tidak ada boundary domain, kontrak internal longgar, atau dependensi silang tidak terkendali—refactor bisa menjadi terlalu mahal. Dalam kasus seperti ini, rewrite pada komponen inti kadang lebih murah daripada terus menambal.

Kapan Cukup Refactor, Bukan Rewrite

Refactor biasanya cukup jika masalahnya masih dapat dilokalisasi tanpa mengganti fondasi runtime. Contoh:

  • Monolith terlalu gemuk tetapi domain masih bisa dipisah per modul.
  • Endpoint tertentu lambat karena query dan serialisasi.
  • Worker tidak stabil karena retry, idempotency, atau pembagian job yang buruk.
  • Memory tinggi karena cache atau object retention, bukan karakter runtime secara fundamental.

Pada kondisi seperti ini, sasaran yang lebih tepat biasanya:

  • modular monolith,
  • ekstraksi service untuk workload spesifik,
  • perbaikan async boundary,
  • pengurangan coupling antarmodul,
  • standarisasi kontrak API internal.

Aturan praktis: jika Anda belum bisa menuliskan komponen mana yang harus ditulis ulang, bottleneck apa yang akan hilang, dan metrik apa yang akan membaik, kemungkinan Anda belum butuh rewrite.

Alternatif yang Sering Lebih Masuk Akal: Split Service atau Modular Monolith

Modular monolith

Jika masalah utama adalah kompleksitas organisasi kode, modular monolith sering menjadi langkah paling bernilai. Anda tetap memakai runtime yang sama, tetapi memaksa boundary yang jelas:

  • setiap domain punya interface eksplisit,
  • akses database dibatasi per modul,
  • dependency antarmodul dikontrol,
  • test integrasi fokus pada kontrak.

Keuntungannya, migrasi lebih murah dan tidak menambah beban operasional seperti service discovery, observability antarservice, atau konsistensi data lintas layanan.

Split service untuk hotspot

Jika hanya satu bagian sistem yang benar-benar CPU-bound atau membutuhkan runtime berbeda, ekstrak bagian itu menjadi service terpisah lebih aman daripada rewrite total. Contohnya:

  • image processing, PDF rendering, atau compression worker,
  • rule engine yang berat secara CPU,
  • stream processor atau ingestion pipeline,
  • gateway dengan throughput sangat tinggi.

Pendekatan ini memberi dua keuntungan besar: Anda membatasi risiko migrasi dan bisa menguji manfaat runtime baru pada satu komponen yang terukur.

Contoh boundary yang sehat

Client
  -> API Backend Utama
       -> Service Auth
       -> Service Billing
       -> Worker/Service Komputasi Berat
       -> Database / Cache / Queue

Dengan pola ini, backend utama tetap menjaga ergonomi pengembangan, sedangkan komponen yang benar-benar kritis secara performa bisa memakai runtime lain.

Checklist Evaluasi Sebelum Memutuskan Rewrite

Checklist teknis

  • Apakah bottleneck utama sudah dibuktikan dengan profiling, tracing, dan metrik produksi?
  • Apakah masalah dominan ada pada CPU, memory, GC/allocation, atau justru database dan jaringan?
  • Apakah workload yang bermasalah cukup terisolasi untuk dipindah sebagian?
  • Apakah ada kontrak API yang jelas untuk menjalankan dua sistem secara paralel?
  • Apakah test integrasi dan regression test sudah cukup untuk memverifikasi perilaku lama vs baru?

Checklist biaya operasional

  • Berapa lama tim harus memelihara dua stack sekaligus?
  • Apakah CI/CD, observability, dan incident response untuk stack baru sudah siap?
  • Apakah ada biaya pelatihan, hiring, atau ketergantungan pada engineer tertentu?
  • Apakah deployment artifact, image size, startup time, dan packaging menjadi lebih rumit?

Checklist risiko downtime dan migrasi

  • Apakah migrasi bisa dilakukan dengan shadow traffic, canary, atau routing bertahap?
  • Apakah format data, schema, dan kontrak API kompatibel?
  • Apakah rollback bisa dilakukan cepat tanpa migrasi data yang sulit dibalik?
  • Apakah ada idempotency dan deduplikasi untuk job/queue selama fase transisi?

Checklist maintainability jangka panjang

  • Apakah stack baru mengurangi kompleksitas inti, atau hanya memindahkannya?
  • Apakah engineer baru bisa produktif dalam waktu wajar?
  • Apakah debugging production incident akan menjadi lebih mudah atau lebih sulit?
  • Apakah dependency kritikal di stack baru cukup matang dan stabil?

Contoh Skenario: Tim Kecil vs Growth Stage

Skenario 1: Tim kecil, produk masih berubah cepat

Misalnya tim berisi 4 engineer, trafik mulai naik, beberapa endpoint melambat, dan biaya server meningkat. Dalam kondisi ini, rewrite penuh hampir selalu keputusan buruk kecuali sistem benar-benar tidak bisa dijalankan.

Prioritas yang lebih masuk akal:

  1. Tambahkan observability dasar: tracing, slow query log, error budget.
  2. Identifikasi 3 endpoint atau worker paling mahal.
  3. Refactor boundary modul yang paling sering berubah.
  4. Pindahkan tugas berat ke worker terpisah bila perlu.
  5. Ekstrak satu komponen ke runtime lain hanya jika manfaatnya jelas.

Untuk tim kecil, kecepatan belajar dan merilis perubahan biasanya lebih penting daripada mengejar performa teoritis. Rewrite besar dapat menghentikan delivery fitur berbulan-bulan tanpa jaminan hasil.

Skenario 2: Tim growth stage, trafik tinggi, bottleneck berulang

Bayangkan tim sudah memiliki observability matang, traffic stabil tinggi, workload komputasi berat makin dominan, dan biaya infrastruktur naik terus. Profiling menunjukkan hotspot konsisten pada parsing, transformasi, atau compute path yang sama. Di sini, rewrite parsial jauh lebih masuk akal.

Langkah yang lebih aman:

  1. Tentukan komponen target yang sempit dan terukur.
  2. Buat kontrak input-output yang stabil.
  3. Bangun implementasi baru di samping sistem lama.
  4. Uji dengan shadow traffic atau replay traffic produksi.
  5. Canary rollout bertahap dan bandingkan error rate, latency, serta resource usage.

Pada tahap ini, rewrite bukan proyek ideologis, melainkan investasi terukur pada komponen yang sudah terbukti mahal secara performa dan operasional.

Pola Implementasi Migrasi yang Lebih Aman

Jika rewrite memang diputuskan, hindari pendekatan sekali pindah. Gunakan migrasi bertahap dengan kontrak yang eksplisit.

// Pseudocode routing bertahap
if (featureFlag("new_runtime_for_pdf")) {
  return callNewService(request)
}
return callLegacyService(request)

Pola seperti ini memungkinkan:

  • perbandingan output lama vs baru,
  • canary berdasarkan tenant atau persen traffic,
  • rollback cepat tanpa downtime besar,
  • validasi metrik produksi sebelum cutover penuh.

Untuk workload asynchronous, gunakan strategi serupa di level queue consumer: jalankan consumer baru pada subset job tertentu, ukur error rate dan throughput, lalu naikkan porsi traffic secara bertahap.

Kesalahan Umum Saat Memilih Runtime atau Melakukan Rewrite

  • Menukar masalah arsitektur dengan masalah bahasa: desain buruk tetap buruk di runtime mana pun.
  • Terlalu percaya benchmark mikro: hasil benchmark kecil jarang mewakili sistem produksi dengan database, jaringan, cache, dan retry.
  • Mengabaikan tooling dan operability: performa tinggi tidak berguna jika insiden sulit dipulihkan.
  • Big bang rewrite: risiko bug, regressions, dan kehilangan parity fitur sangat tinggi.
  • Tidak menyiapkan metrik sukses: tanpa target yang jelas, rewrite mudah berubah menjadi proyek tanpa akhir.

Kerangka Keputusan Singkat

  1. Ukur dulu: tentukan bottleneck nyata dengan profiling dan tracing.
  2. Perbaiki lapisan termurah: query, cache, I/O, batching, concurrency limit, queueing.
  3. Refactor jika boundary bermasalah: modular monolith atau split service.
  4. Rewrite parsial jika bottleneck fundamental tetap ada: terutama untuk komponen CPU-bound atau memory-sensitive.
  5. Rewrite besar hanya jika biaya menambal sudah kalah dan tim siap menjalankan migrasi bertahap dengan kontrol risiko yang baik.

Penutup

Memilih runtime backend seharusnya bukan keputusan emosional atau identitas teknologi, tetapi keputusan ekonomi-teknis yang didukung data. Rewrite layak dilakukan ketika batas fundamental runtime memang menjadi hambatan utama, ketika manfaatnya bisa diukur, dan ketika migrasi dapat dikendalikan secara bertahap. Di luar itu, optimasi bertahap, refactor arsitektur, modular monolith, atau ekstraksi service sempit biasanya memberi hasil lebih cepat dengan risiko yang jauh lebih rendah.

Jika Anda belum bisa menunjukkan komponen mana yang harus di-rewrite, bottleneck apa yang akan hilang, metrik apa yang membaik, dan bagaimana rollback dilakukan, kemungkinan keputusan terbaik saat ini bukan rewrite—melainkan memahami sistem yang ada dengan lebih baik.