# Monorepo Polyrepo Farkı Hangisi Seçilmeli: Veriyle Cevap URL: https://upstreamapi.com/tr/journal/monorepo-polyrepo-farki-hangisi-secilmeli Type: blog Locale: tr Published: 2026-09-12 Updated: 2026-09-13 --- > Monorepo ve polyrepo arasındaki seçimi ekip tercihine değil veriye dayandırın. Faros AI benchmark, koordinasyon vergisi ve araç maliyeti analizi. "Monorepo polyrepo farkı hangisi seçilmeli" sorusunun cevabı bir tavsiye değil, bir ölçümdür. Özellikle şu soru: özelliklerinizin yüzde kaçı birden fazla servis sınırını aşan değişiklikler gerektiriyor? Bu sayıyı bilmiyorsanız, bir altyapı kararını veriyle değil ekip tercihine göre alıyorsunuzdur. 50 kişilik bir mühendislik organizasyonunda bu tercih birine bir Pazar gecesine mal olacak. Asıl mesele hesaplamadır. Her iki yaklaşım da maliyet getirir. Soru şu: organizasyonunuz hangi maliyeti daha iyi absorbe edebilir; polyrepo'nun koordinasyon vergisi mi yoksa monorepo'nun araç yatırımı mı? Bu soruya verilen yanıt veriyle desteklendiğinde mimari tartışma ekip dinamiğinden kurtulup mühendislik kararına dönüşüyor. Her iki seçeneğin de gerçek maliyetleri var. Koordinasyon vergisi zamanla gizlice birikir ve çoğu zaman ölçülmez. Araç yatırımı ise görünür ve tartışmaya açık. Bu asimetri, polyrepo'nun olduğundan daha ucuz, monorepo'nun olduğundan daha pahalı görünmesine yol açıyor. ## PR Süre Verileri Bu Tartışmayı Çözüyor. Çözmüyor. [Faros AI, 320 mühendislik ekibini](https://www.faros.ai/blog/monorepo-vs-polyrepo-benchmark-data) 12 ay boyunca analiz etti ve monorepo ortamlarında medyan PR süresinin 19 saat olduğunu buldu. Polyrepo ortamlarında ise 2 saat. Medyanda 9,5 kat fark var. 90. yüzdelik dilimde fark daralıyor: 8,6 güne karşı 5,5 gün. Her iki kuyruk da yavaş. Ortalamada da fark küçülüyor: monorepo için 3,6 gün, polyrepo için 2,8 gün. Bu sayıların gerçekte ne anlama geldiğini kavramak için veriyi üreten koşulları ve ekip yapılarını anlamak şart. Karşı argüman iyi biliniyor: önbellek işe yaradığında monorepo bireysel build sürelerini hızlandırıyor. Beş ayrı repository'de, beş ayrı CI pipeline'ıyla ve beş ayrı CODEOWNERS onayıyla çapraz-servis değişikliği koordine eden bir polyrepo ekibi de PR'ı 2 saatte kapatamıyor zaten. Veri tipik PR'ların süresini ölçüyor; en kötü senaryodaki çapraz değişiklikleri değil. Bu ayrım kritik. Polyrepo ekipler medyanlarını öne sürerek konuşuyor (hızlı, çünkü PR'larının büyük çoğunluğu izole). Monorepo savunucuları repository'ler arası koordinasyonun acısından bahsediyor (gerçek ve en kötü durum PR kuyruklarında belgelenmiş). Her iki taraf da farklı senaryolar için haklı. Veri tartışmayı çözmüyor. Ama takas dengesini net sezgiden çok daha kesin biçimde tarif ediyor. Hangi tarafın haklı olduğu, sizin ekibinizin hangi tür PR'larla geçirdiği zamana bakınca netleşiyor. Mono mu poly mu; bu soruyu sormadan önce kendi PR dağılımınıza bakın. ![SRE mühendisi birden fazla dashboard ile çalışma istasyonunda deployment metriklerini izliyor](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/6a5eb6-inline1.webp) ## Hesaplamadığınız Patlama Yarıçapı Konferans sunumlarında nadiren yer alan şu var: monorepo'da bozuk bir paylaşımlı bağımlılık, onu import eden her servisi aynı commit'te, aşağı akış sahipliği olan kimse değişikliği incelemeden etkiliyor. Polyrepo'da ise bozuk bir paket versiyonu yalnızca onu yükselten servisleri etkiliyor; ama yalnızca yükselttiklerinde. Patlama yarıçapı erteleniyor ve tüketici tercihiyle sınırlı kalıyor. Bağımlılık yükseltemediğinizde eskide kalan sürümler birikiyor; bu da ayrı bir problem. Ama en azından kim ne zaman etkileneceğini kontrol edebiliyor. Bu, SLO-gated rollout'lar için kritik bir fark. Monorepo'da kötü bir paylaşımlı kütüphane size canary penceresi vermiyor. Tek bir deployment olayında çapraz-servis patlama yarıçapı veriyor. Rollout otomasyonunuz deseni tespit edip revert tetiklemeden önce birden fazla SLO'ya karşı aynı anda hata bütçeniz yanmaya başlıyor. Polyrepo'da paylaşımlı bağımlılık değişikliğinin yayılımı yapısı gereği ardışık. A servisi yükseltiyor, SLO'sunu izliyorsunuz. B servisi üç gün sonra yükseltiyor. Herhangi bir anda patlama yarıçapı, değişikliği zaten benimseyen servislerin sayısıyla sınırlı kalıyor. Soru hangi yapının doğasında daha güvenli olduğu değil; deployment primitif'inizin ne olduğu. Deployment birimin kendi SLO kapısı olan servis ise polyrepo doğal izolasyon sunuyor. Deployment birimin frontend, API ve arka plan worker'ı aynı anda tutarlı biçimde kapsayan atomik özellik değişikliği ise monorepo bu koordinasyonu versiyonlama kayması olmadan sağlıyor. Mikroservis ship eden ekiplerin çoğunun birinci sorunu var. Sıkı bağlı bir ürün yüzeyi ship edenlerin çoğunun ikinci. Bu ayrımı net yapmak, beklentilerin hangi yapıyla karşılanacağını ve hangisinin bedelini ödeyeceğinizi belirlemenin başlangıç noktası. ## Polyrepo Ekipler 50 Mühendiste Neden Koordinasyon Duvarına Çarpıyor Koordinasyon vergisi birikerek büyüyor. 8 mühendiste dört repository yönetmek sinir bozucu ama yapılabilir. 50 mühendiste ise birkaç kişi için yarı zamanlı iş haline geliyor. Polyrepo koordinasyon yükünün yapısal soruna dönüştüğünün somut işaretleri: - Platform ekibiniz, hiç kimsenin net sahipliğinin olmadığı bir shared-libraries repository'si yönetiyor - Servisler arası versiyonlama o kadar sapmış ki paylaşımlı kütüphaneyi yükseltmek iki haftalık bir projeye dönüşüyor - Yeni bir mühendis, önce hangi 23 repository'den klonlayacağını anlamadan üretken olamıyor - Paylaşımlı bağımlılıklara güvenlik yamaları, bir takip tablosuyla düzinelerce repo'da koordineli PR gerektiriyor Bunların hiçbiri uydurma patoloji değil. 80 mühendise ulaşıp repo kararlarına pişmanlıkla bakan ekiplerin belgelenmiş başarısızlık modları. Pişmanlık genellikle yavaş gelişiyor: her çeyrek biraz daha fazla zaman harcanıyor, ta ki mühendisler çoğunlukla koordinasyonla uğraşmak için değil ürün geliştirmek için işe alındıklarını düşünüp şikayet etmeye başlayana kadar. Polyrepo, ekipler gerçekten bağımsız olduğunda işe yarıyor: farklı yayın döngüleri, farklı teknoloji yığınları, farklı nöbet rotasyonları. Ekipler yeterince kod paylaştığında; bir servisteki değişiklik diğer üçü hakkında akıl yürütmeyi gerektirdiğinde, polyrepo'nun sağladığı izolasyon koordinasyonu acı veren mekanizmaya dönüşüyor. Satın aldığınız özgürlük, koordinasyon borcuna dönüşüyor. Organizasyonel belirti: çapraz-repo yayınlarını koordine etmek için kaç Slack kanalının özellikle açıldığını sayın. Cevap sıfırdan fazlaysa, koordinasyon vergisini tutarlı biçimde ödemeye zaten başlamışsınızdır. Bu kanallar verimsizliğin göstergesi değil; yapısal bir seçimin bedelidir. ## Monorepo'nun 95. Yüzdelik Dilimde Gerçek Maliyeti Faros AI'ın P90 verisi öğretici: 90. yüzdelik dilimde monorepo PR'ları için 8,6 gün. Bu yavaş bir ekip değil; birden fazla kod sahibi gerektiren, daha geniş CI matrisi ve organizasyon sınırlarını aşan inceleme döngüleri içeren büyük çapraz değişikliklerin yapısal sonucu. Google'ın Bazel'i var. Meta Buck inşa etti. Nx Cloud ve Turborepo uzak önbellekleri, monorepo'yu performanslı kılmak için gereken araç yatırımının önemsiz olmadığı için var. 200 mühendis ölçeğinde etkilenen-servis seçimli build, dağıtık önbellek ve otomatik merge kuyruğu olmayan bir monorepo, paylaşımlı bir yardımcı fonksiyona dokunan PR'larda 45 dakikalık CI çalışmaları üretiyor. Araç maliyeti gerçek ve rutin olarak hafife alınıyor. Monorepo'yu ölçekte başarıyla işleten ekipler genellikle bu altyapıya özellikle odaklı platform mühendisleri işe almış. Büyüyen bir kod tabanına ürün geliştirirken monorepo araçlarını sonradan eklemek, post-mortem'den önce deployment sıklığına yansıyan bir yük haline geliyor. Ekip bunu genellikle bir sonraki çeyreğe öteliyor; ta ki CI süreleri ürün hızını fiilen yavaşlatana kadar. Platform ekibiniz zaten gergin durumdaysa, monorepo araç bakımı eklemek anlamlı bir taahhüt; yapılandırma tercihi değil. ![Beyaz tahta üzerinde mimari diyagram, monorepo ve polyrepo için dallanmış pipeline yapılarını gösteriyor](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/upstreamapi/2026-09/6dbec8-inline2.webp) ## Yüksek Performanslı Ekiplerin Kullandığı Yüzde 30 Kuralı Bu kararı bilinçli veren ekiplerde faydalı bir pratik kural var: özelliklerinizin yüzde 30'dan fazlası birden fazla servis sınırı aşan değişiklikler gerektiriyorsa, polyrepo'nun koordinasyon yükü eninde sonunda iyi işletilen bir monorepo'nun araç yatırımını aşacak. Yüzde 30'un altında (çoğu mikroservis organizasyonunun bulunduğu yer) polyrepo'nun izolasyon faydaları genellikle koordinasyon vergisini geçiyor. Çapraz-servis değişiklikleri oluyor, ama paylaşımlı araçların izolasyondan daha hızlı karşılık ödemesini sağlayacak sıklıkta değil. Bu tamamen ölçülebilir bir şey. Son altı ayın birleştirilen PR'larını çekin ve kaç tanesinin tek bir kullanıcıya yönelik özellik göndermek için birden fazla repository'de değişiklik gerektirdiğini sayın. Bu oran girdiniz. Ondalık hassasiyette olmayacak ama yön gösterecek; tartışmanın ekip tercihiyle sürüklenmemesi için yeterli. Mühendislik kararları bu tür yönlendirici metriklerle daha sağlıklı veriliyor. Yüzde 12 çapraz-servis oranına sahip bir ekibin monorepo'ya ihtiyacı yok. Yüzde 38'de olan ve büyüyen ekip, büyümeye devam edecek koordinasyon vergisini ödüyor. İki senaryo arasındaki fark yüzde 26'lık oran değil; onun altında yatan özellik mimarisi tercihleridir. Bu ölçüm bir kerelik değil. Organizasyon büyüdükçe, yeni ekipler eklendikçe ve ürün stratejisi değiştikçe oran kayıyor. Çeyreklik bir kontrol alışkanlığı, kararı doğru zamanda gözden geçirmenizi sağlıyor. ## Rollout Stratejisi Denklemi Nasıl Değiştiriyor Bu kararın neredeyse hiç ele alınmayan bir boyutu var: rollout primitif'iniz. SLO kapılı yüzde-tabanlı rollout'lar işletiyorsanız (bir özelliği trafiğin yüzde 5'ine gönderip hata bütçelerini izleyerek kademeli olarak genişletiyorsanız) patlama yarıçapı hesabınız özelliğin bir servise mi yoksa birkaçına mı yayıldığına göre değişiyor. Polyrepo'da çok-servisli özellik rollout'u, rollout durumunun servisler arası koordinasyonunu gerektiriyor. A servisi yüzde 20'de olabilirken B servisi hala yüzde 0'da olabiliyor. Bu olay koşullarında hakkında akıl yürütmesi gerçekten güç tutarsız durumlar yaratıyor. Feature flag'ler yardımcı oluyor, ama rollout ilerlemesi için tek bir gerçek kaynağı olmadan çapraz-servis flag durumunu yine de yönetiyorsunuz. Atomik commit'lere sahip monorepo'da özellik servisler arası tutarlı biçimde iniyor. Rollout altyapı düzeyinde hala yüzde-tabanlı olabilir, ama kod deployment'ın gerçekleştiği andan itibaren tutarlı. SLO kapılarınız tutarlı bir duruma karşı ateşleniyor. Bu fark gece yarısı bir uyarı aldığınızda hangi serviste ne olduğunu anlamak için harcanan zihinsel enerjiyi doğrudan etkiliyor. Çok sayıda atomik çok-servisli özellik geliştirip SLO ihlalinde otomatik rollback'le yüzdelik rollout işleten ekipler, monorepo'nun tutarlılığının polyrepo'nun temiz bir adı olmayan olay kategorisini ortadan kaldırdığını sıklıkla görüyor: gerçekte bir dağıtım koordinasyon sorunu olan ama yazılım hatası gibi görünen çapraz-servis durum sapması olayı. ## Post-Mortem Aslında Ne Söyleyecek Mühendislik organizasyonlarının çoğu, kimsenin hibrit demediği bir hibrit üzerinde sonuçlanıyor; çünkü mimari taviz gibi kulağa geliyor. Ama bu taviz değil, olgunlaşma. Sıkı bağlı ürün yüzeyleri için bir ya da iki monorepo. Bağımsız deployment döngülerine, kendi nöbet rotasyonuna sahip olan ve altı ayda bir paylaşımlı kütüphane değişikliği koordine etmek zorunda kalmayan gerçekten özerk servisler için ayrı repository'ler. Mevcut kurulumunuzu gözden geçirmenizi gerektiren sinyaller: - Çapraz-servis değişiklik sıklığı yüzde 30'u geçti ve CI çalışma süreleri birikerek artıyor - Monorepo araçlarına yatırım yapmaya kapasitesi olan platform mühendisleri işe aldınız - Bir patlama yarıçapı olayı polyrepo izolasyonunuzun sahte olduğunu ortaya koydu: servisler yeterince altyapı paylaşıyordu, izolasyon güvenlik değil konfor sağlıyordu Kararın şimdilik iyi olduğunun sinyalleri: - Ekipler gerçekten bağımsız ve koordinasyon yükü düşük - En kötü olayınız çapraz-servis bağımlılık kaymasından kaynaklanmadı - Ürün geliştirmeyi yavaşlatmadan monorepo araçlarını sürdürecek platform mühendisliği kapasitesi yok Post-mortem, gerçekte hangisinde yaşadığınızı söyleyecek. Bu belge genellikle tarif ettiği sistemi önceleyen mimari karar kaydından daha dürüst. Çünkü karar kaydı ekibin istediği şeyi, post-mortem ise üretimde ne olduğunu anlatır. Kararı verirken post-mortem sorusunu önceden sormak; o belgeyi sonradan yazmak zorunda kalmamak için en etkili yol. ## FAQ ### Monorepo polyrepo farkı hangisi seçilmeli sorusunun kesin bir yanıtı var mı? Kesin bir yanıt yok. Cevap ekibinizin özelliklerinin yüzde kaçının birden fazla servis sınırı gerektirdiğine bağlı. Faros AI verisi yönlendirici ama karar organizasyonunuzun özel bağlamına, platform kapasitesine ve rollout stratejisine göre verilmeli. ### Monorepo ile polyrepo arasındaki PR süresi farkı ne kadar? Faros AI'ın 320 ekip analizi: monorepo medyan PR süresi 19 saat, polyrepo 2 saat. Bu 9,5 kat fark. 90. yüzdelik dilimde fark daralıyor: monorepo 8,6 gün, polyrepo 5,5 gün. Ortalamada ise monorepo 3,6 gün, polyrepo 2,8 gün. ### Yüzde 30 kuralı ne demek ve nasıl hesaplanıyor? Son altı ayın birleştirilen PR'larını çekin ve kaç tanesinin birden fazla repository'de değişiklik gerektirdiğini sayın. Bu oran yüzde 30'u aşıyorsa monorepo'nun koordinasyon faydaları araç yatırımını karşılamaya başlıyor. Altında kalıyorsanız polyrepo'nun izolasyon avantajları öne çıkıyor. ### Monorepo'nun araç maliyeti gerçekten yüksek mi? Evet. Bazel, Buck, Nx Cloud veya Turborepo gibi sistemler gerekiyor. 200 mühendis ölçeğinde etkilenen-servis seçimli build ve dağıtık önbellek olmadan 45 dakikalık CI çalışmaları normal. Başarılı ekipler bu altyapıya özellikle odaklı platform mühendisleri işe almak zorunda kalıyor. ### Polyrepo koordinasyon sorunu neden tam olarak 50 mühendiste ortaya çıkıyor? 8 mühendiste yönetilebilir olan versiyonlama sapması, belirsiz shared library sahipliği ve çapraz-repo güvenlik yamaları birikerek yapısal sorunlara dönüşüyor. 50 mühendiste bu görevler birkaç kişi için yarı zamanlı işe dönüşüyor; 80 mühendiste ise koordinasyon yükü belgelenmiş başarısızlık moduna giriyor. ### Rollout stratejisi mimari seçimini nasıl etkiliyor? Polyrepo'da çok-servisli rollout koordinasyonu güç: A servisi yüzde 20'de, B servisi hala yüzde 0'da olabiliyor. Monorepo'da atomik commit'ler deployment anından itibaren tutarlı kod sağlıyor; SLO kapıları tutarlı bir duruma karşı ateşleniyor ve çapraz-servis durum sapması olaylarını önlüyor. ### Hibrit yaklaşım geçerli bir seçenek mi? Evet. Sıkı bağlı ürün yüzeyleri için monorepo, gerçekten özerk servisler için ayrı repository tercih edilebilir. Büyük mühendislik organizasyonlarının çoğu farklı özellik sıklıklarına göre bu hibrit yapıda sonuçlanıyor.