# Monorepo vs Polyrepo Perbedaan: Ukur Sebelum Memilih URL: https://upstreamapi.com/id/journal/monorepo-vs-polyrepo-perbedaan Type: blog Locale: id Published: 2026-09-12 Updated: 2026-09-13 --- > Monorepo vs polyrepo bukan soal preferensi tim. Ini soal pengukuran: berapa persen fitur Anda butuh perubahan di lebih dari satu service boundary? Pertanyaan soal **monorepo vs polyrepo perbedaan** bukan soal rekomendasi. Ini soal pengukuran. Konkretnya: berapa persen fitur Anda membutuhkan perubahan di lebih dari satu service boundary? Jika Anda tidak tahu angka itu, Anda sedang membuat keputusan infrastruktur berdasarkan preferensi tim, bukan data. Di organisasi dengan 50 engineer, preferensi itu akan menelan hari Minggu seseorang. Kuncinya adalah *kalkulasi*. Kedua pendekatan membawa biaya. Pertanyaannya: biaya mana yang lebih bisa diserap organisasi Anda? Pajak koordinasi polyrepo, atau investasi tooling monorepo? Tidak ada jawaban universal karena pertanyaannya sendiri bergantung pada frekuensi perubahan lintas service di tim Anda, dan angka itu berbeda di setiap organisasi. ## Data PR Cycle Time: Fakta yang Tidak Menyelesaikan Debat [Faros AI menganalisis 320 tim engineering](https://www.faros.ai/blog/monorepo-vs-polyrepo-benchmark-data) selama 12 bulan dan menemukan bahwa lingkungan monorepo memiliki median PR cycle time sebesar 19 jam. Lingkungan polyrepo: 2 jam. Selisih 9,5 kali di median. Di persentil ke-90, selisih menyempit menjadi 8,6 hari versus 5,5 hari, tetapi kedua ekor distribusi sama-sama lambat. Mean juga menyempit: 3,6 hari monorepo, 2,8 hari polyrepo. Argumen balik sudah terdokumentasi: monorepo memiliki build time individu yang lebih cepat ketika cache bekerja dengan baik. Tim polyrepo yang mengkoordinasikan perubahan lintas service di lima repositori, dengan lima pipeline CI terpisah dan lima CODEOWNERS sign-off terpisah, tidak akan menutup PR dalam dua jam juga. Data ini menangkap cycle time untuk PR tipikal, bukan perubahan cross-cutting kasus terburuk. Perbedaan itu penting. Tim polyrepo mengutip median mereka yang cepat, karena sebagian besar PR mereka terisolasi. Advokat monorepo mengutip rasa sakit koordinasi lintas repo, yang juga nyata dan terdokumentasi di ekor PR terburuk mereka. Kedua sisi benar untuk skenario yang berbeda. Data tidak menyelesaikan debat. Ia mendeskripsikan tradeoff lebih presisi daripada perasaan. Perbedaan sesungguhnya terletak pada apa yang Anda ukur, bukan pada angka mana yang lebih besar. ![Engineer SRE memantau metrik deployment di workstation dengan beberapa dashboard](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/6a5eb6-inline1.webp) ## Blast Radius yang Jarang Diperhitungkan Ini yang jarang muncul di slide conference: dalam monorepo, dependensi shared yang rusak mendarat di setiap service yang mengimpornya, dalam commit yang sama, sebelum siapapun dengan downstream ownership sempat mereview perubahan itu. Dalam polyrepo, paket yang rusak memengaruhi service yang meng-upgrade-nya, tetapi hanya ketika mereka meng-upgrade-nya. Blast radius ditangguhkan dan dibatasi oleh pilihan consumer. Ini penting untuk rollout dengan SLO gate. Library shared yang buruk dalam monorepo tidak memberikan canary window. Ia memberikan blast radius lintas service dalam satu deployment event. Error budget mulai terbakar di beberapa SLO secara bersamaan sebelum otomasi rollout Anda dapat mendeteksi pola dan memicu revert. Dalam polyrepo, rollout perubahan dependensi shared bersifat sekuensial secara alami. Service A meng-upgrade dan Anda mengamati SLO-nya. Service B meng-upgrade tiga hari kemudian. Blast radius pada titik waktu manapun dibatasi oleh siapa yang sudah mengadopsi perubahan tersebut. Pertanyaannya bukan mana yang secara inheren lebih aman. Pertanyaannya adalah apa deployment primitive Anda. Jika unit deployment Anda adalah service dengan SLO gate-nya sendiri, polyrepo memberikan isolasi natural. Jika unit deployment Anda adalah perubahan fitur atomik yang mendarat konsisten di frontend, API, dan background worker secara bersamaan, monorepo memberikan koordinasi itu tanpa version drift. Sebagian besar tim yang shipping microservices menghadapi masalah pertama. Sebagian besar tim yang shipping product surface yang tightly coupled menghadapi masalah kedua. ## Mengapa Tim Polyrepo Mentok di 50 Engineer Pajak koordinasi terakumulasi. Pada 8 engineer, mengelola empat repositori menjengkelkan tapi masih bisa dilakukan. Pada 50, itu menjadi pekerjaan paruh waktu bagi beberapa orang. Dan pada 80 engineer, Anda sudah melihat dampaknya di deployment frequency sebelum menyadari penyebabnya. Tanda-tanda konkret bahwa overhead koordinasi polyrepo sudah menjadi struktural: - Tim platform Anda memelihara repo shared-libraries yang tidak ada yang memiliki ownership jelas - Versioning lintas service sudah terdrift cukup jauh sehingga bumping shared library adalah proyek dua minggu - Engineer baru tidak bisa produktif tanpa memahami mana dari 23 repositori Anda yang harus di-clone pertama - Security patch ke dependensi shared membutuhkan PR terkoordinasi di selusin repo, dengan spreadsheet tracking Tidak satupun dari ini patologi yang dibuat-buat. Ini adalah failure mode yang terdokumentasi dari tim yang mencapai 80 engineer dan melihat ke belakang pada keputusan repo mereka dengan penyesalan. Polyrepo berhasil ketika tim benar-benar independen: release cycle berbeda, tech stack berbeda, on-call rotation berbeda. Ketika tim berbagi cukup banyak kode sehingga perubahan di satu service mengharuskan reasoning tentang tiga service lain, isolasi yang polyrepo beli menjadi mekanisme yang membuat koordinasi menyakitkan. Tanda organisasional: hitung berapa channel Slack yang ada secara spesifik untuk mengkoordinasikan cross-repo release. Jika jawabannya lebih dari nol, Anda sudah mulai membayar pajak koordinasi secara konsisten. Kalau jawabannya tiga atau lebih, Anda sudah lama membayarnya tanpa menyadarinya. ## Biaya Nyata Monorepo di Persentil ke-95 Data P90 dari Faros AI instruksional: 8,6 hari untuk PR monorepo di persentil ke-90. Itu bukan tim yang lambat. Itu konsekuensi struktural dari perubahan cross-cutting besar yang membutuhkan koordinasi di beberapa code owner, CI matrix yang lebih luas, dan review cycle yang merentang batas organisasi. Google punya Bazel. Meta membangun Buck. Nx Cloud dan Turborepo remote cache ada karena investasi tooling untuk membuat monorepo berkinerja baik tidak sepele. Monorepo dengan 200 engineer tanpa affected-only build selection, distributed caching, dan automated merge queue menghasilkan CI run 45 menit pada PR yang menyentuh fungsi utilitas shared. Biaya tooling nyata dan secara rutin diremehkan. Tim yang berhasil mengoperasikan monorepo dalam skala besar biasanya sudah merekrut platform engineer yang secara khusus fokus pada infrastruktur itu. Meng-retrofit tooling monorepo ke codebase yang berkembang sambil juga shipping product adalah beban yang muncul di deployment frequency sebelum muncul di post-mortem. Jika tim platform Anda sudah kewalahan, menambahkan pemeliharaan tooling monorepo adalah komitmen yang berarti, bukan sekadar pilihan konfigurasi. Keputusan ini harus masuk ke capacity planning, bukan hanya ke arsitektur decision record. ![Diagram arsitektur di whiteboard menampilkan struktur pipeline bercabang untuk monorepo dan polyrepo](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/6dbec8-inline2.webp) ## Aturan 30 Persen yang Dipakai Tim Berkinerja Tinggi Heuristik berguna dari tim yang sudah membuat keputusan ini dengan sengaja: jika lebih dari 30% fitur Anda membutuhkan perubahan di beberapa service boundary, overhead koordinasi polyrepo pada akhirnya akan melampaui investasi tooling monorepo yang dijalankan dengan baik. Di bawah 30%, di mana sebagian besar organisasi microservices berada, manfaat isolasi polyrepo biasanya melebihi pajak koordinasi. Perubahan lintas service terjadi, tetapi tidak cukup sering untuk membuat shared tooling terbayar lebih cepat daripada isolasi yang ada. Ini terukur. Tarik enam bulan terakhir PR yang sudah di-merge dan hitung berapa yang membutuhkan perubahan di lebih dari satu repositori untuk shipping satu fitur yang menghadap pengguna. Rasio itu adalah input Anda. Tidak akan tepat hingga satu desimal, tetapi akan directional, dan directional sudah cukup untuk menghentikan debat yang berjalan berdasarkan preferensi tim. Tim dengan tingkat cross-service 12% tidak membutuhkan monorepo. Tim di angka 38% dan terus bertumbuh membayar pajak koordinasi yang akan terus terakumulasi. Angka itu yang menentukan arah keputusan, bukan ukuran tim atau preferensi arsitektur yang berlaku saat ini. ## Strategi Rollout Mengubah Semua Kalkulasi Ada dimensi keputusan ini yang hampir tidak pernah dapat coverage: rollout primitive Anda. Jika Anda menjalankan percentage-based rollout dengan SLO gate, shipping fitur ke 5% traffic, mengamati error budget, lalu secara progresif memperluas, kalkulasi blast radius Anda berubah tergantung apakah fitur merentang satu service atau beberapa. Dalam polyrepo, rollout fitur multi-service membutuhkan koordinasi state rollout lintas service. Service A bisa di 20% sementara Service B masih di 0%, menciptakan state yang tidak konsisten yang sangat sulit di-reason di bawah kondisi insiden. Feature flag membantu, tetapi Anda tetap mengelola state flag lintas service tanpa single source of truth untuk progress rollout. Dalam monorepo dengan atomic commit, fitur mendarat konsisten di semua service. Rollout masih bisa percentage-based di level infrastruktur, tetapi kodenya konsisten sejak momen deploy terjadi. SLO gate Anda firing terhadap state yang koheren, bukan state yang terpecah antara beberapa repositori yang belum tentu tersinkronisasi. Tim yang banyak melakukan atomic multi-service feature, menjalankan progressive rollout dengan automated rollback pada pelanggaran SLO, sering menemukan bahwa konsistensi monorepo mengeliminasi seluruh kategori insiden yang tidak dimiliki polyrepo nama yang bersih: insiden cross-service state divergence yang terlihat seperti bug tetapi sebenarnya adalah masalah koordinasi deployment. ## Apa yang Akan Tertulis di Post-Mortem Nanti Sebagian besar organisasi engineering berakhir pada hybrid yang tidak ada yang menyebutnya hybrid karena terdengar seperti cop-out arsitektur. Satu atau dua monorepo untuk product surface yang tightly coupled. Repositori terpisah untuk service yang benar-benar otonom dengan deployment cycle independen, on-call rotation mereka sendiri, dan tim yang tidak perlu mengkoordinasikan perubahan shared library dalam enam bulan terakhir. Sinyal untuk meninjau kembali setup saat ini: - Frekuensi perubahan lintas service sudah melampaui 30% dan CI runtime terus bertambah - Anda sudah merekrut platform engineer dengan kapasitas untuk berinvestasi dalam tooling monorepo - Insiden blast radius mengungkapkan bahwa isolasi polyrepo Anda palsu: service berbagi cukup banyak infrastruktur sehingga isolasinya memberikan kenyamanan, bukan keamanan Sinyal bahwa keputusan saat ini masih oke: - Tim benar-benar independen dan overhead koordinasi rendah - Insiden terburuk Anda tidak disebabkan oleh drift dependensi lintas service - Kapasitas platform engineering tidak ada untuk memelihara tooling monorepo tanpa memperlambat product delivery Post-mortem akan mengatakan mana dari ini yang sebenarnya Anda jalani, dan jawabannya biasanya lebih jelas dari yang Anda kira. Dokumen itu biasanya lebih jujur daripada arsitektur decision record yang mendahului sistem yang ia deskripsikan. Dan keputusan yang benar hari ini mungkin berubah satu tahun dari sekarang, ketika komposisi tim atau frekuensi perubahan lintas service Anda bergeser secara signifikan. ## FAQ ### Apa perbedaan utama antara monorepo dan polyrepo? Monorepo menyimpan semua kode dalam satu repositori, memberikan koordinasi atomik tetapi membutuhkan investasi tooling. Polyrepo memisahkan setiap service ke repositori independen, memberikan isolasi natural tetapi menambah overhead koordinasi saat perubahan melintas batas service. Perbedaannya bukan tentang preferensi, melainkan tentang berapa persen fitur Anda yang membutuhkan perubahan lintas service. ### Berapa lama PR cycle time di monorepo vs polyrepo? Menurut analisis Faros AI terhadap 320 tim selama 12 bulan, median PR cycle time monorepo adalah 19 jam dibanding 2 jam untuk polyrepo. Di persentil ke-90, monorepo mencapai 8,6 hari versus 5,5 hari. Perbedaan ini mencerminkan biaya koordinasi struktural, bukan kualitas tim. ### Kapan sebaiknya memilih monorepo? Pertimbangkan monorepo ketika lebih dari 30% fitur Anda membutuhkan perubahan di beberapa service boundary, ketika atomic multi-service deployment penting untuk konsistensi rollout, dan ketika tim platform Anda memiliki kapasitas untuk berinvestasi dalam tooling seperti Bazel, Turborepo, atau Nx Cloud. ### Apa tanda-tanda tim polyrepo sudah perlu beralih ke monorepo? Tanda-tandanya: frekuensi perubahan lintas service melebihi 30%, ada channel Slack khusus untuk koordinasi cross-repo release, bumping shared library menjadi proyek dua minggu, dan security patch membutuhkan PR terkoordinasi di selusin repo dengan spreadsheet tracking. ### Bagaimana monorepo dan polyrepo mempengaruhi blast radius deployment? Dalam monorepo, dependensi shared yang rusak langsung berdampak pada semua service yang mengimpornya dalam satu commit. Dalam polyrepo, blast radius ditangguhkan: service hanya terdampak saat mereka meng-upgrade dependensi yang rusak. Polyrepo memberikan isolasi natural per service, monorepo memberikan konsistensi state yang berguna untuk progressive rollout multi-service. ### Apa aturan 30 persen dalam memilih monorepo vs polyrepo? Jika lebih dari 30% fitur Anda membutuhkan perubahan di beberapa service boundary, overhead koordinasi polyrepo akhirnya akan melampaui investasi tooling monorepo. Di bawah 30%, manfaat isolasi polyrepo biasanya lebih unggul. Ukur rasio ini dari PR yang di-merge dalam enam bulan terakhir. ### Apakah hybrid antara monorepo dan polyrepo memungkinkan? Ya, dan ini adalah pendekatan yang paling banyak digunakan oleh tim besar. Satu atau dua monorepo untuk product surface yang tightly coupled, ditambah repositori terpisah untuk service yang benar-benar otonom dengan deployment cycle dan on-call rotation independen.