Mikroservis mi, Monolit mi: Kurumsal CTO'lar İçin 2026 Karar Çerçevesi

Sorulan yanlış soru

"Mikroservise mi geçelim, monolitte mi kalalım?" — 50–500 kişilik mühendislik organizasyonları yöneten CTO'lardan en sık duyduğumuz mimari sorusu. Aynı zamanda yanlış soru.

Doğru soru daha dar ve daha faydalı: takım büyüklüğümüz, deployment hızımız, veri sahipliği sınırlarımız ve hata toleransımız göz önünde bulundurulduğunda, hangi mimari biçim önümüzdeki 18 ayın maliyetini en aza indirir?

Mikroservis bir olgunluk rozeti değil. Monolit, eski borç işareti değil. 2026'da her ikisi de tamamen saygın tasarım kararları ve doğru cevap neredeyse her zaman beş somut eksene bağlı; geçen çeyrek hangi mimari konferansına gittiğinize değil.

Bu yazı, Internative olarak bir müşteri bu kararı bizden istediğinde kullandığımız çerçeve — 2021'den bu yana her iki mimari biçimde yaklaşık 30 üretim engagement'inden damıttığımız şekliyle.

Aslında ne farklı — kararı belirleyen beş eksen

Pazarlama diyagramlarını unutun. Mikroservis ile monolit arasındaki dürüst fark, beş operasyonel kaygıya iniyor. Karar vermeden önce her birine karşı kendinizi puanlayın.

1. Takım büyüklüğü ve servis sayısı

Mikroservis koordinasyon yükü ekler. Kabaca bir kural olarak, sağlıklı bir mikroservis tipik olarak 3–8 mühendisten oluşan bir takıma uçtan uca sahiplik gerektirir (ürün, kod, deployment, on-call). Mühendislik organizasyonunuz 12 kişiyse, üç mikroservis zaten operasyonel kapasitenizin üzerinde — özellik üretmek yerine servisleri birbirine bağlamakla zaman geçirirsiniz.

Modüler bir kod tabanında monolit, 30–60 mühendise rahatlıkla ölçeklenir. Bu sayının üzerinde deployment çakışmaları acımaya başlar.

2. Deployment hızı

Eğer ürününüzün farklı parçalarının çok farklı hızlarda yayına alınması gerekiyorsa — diyelim ki ayda bir değişen bir ödeme motoru ile günde on kez değişen bir pazarlama sayfası render'ı — mikroservis size bu bağımsızlığı verir. Her servis hazır olduğunda yayına çıkar.

Ürününüz makul şekilde birlikte yayına alınabiliyorsa (orta-erken aşamadaki çoğu B2B SaaS), bağımsız deployment hatlarının maliyeti boşa giden iş.

3. Veri sahipliği sınırları

Çoğu takımın hafife aldığı eksen bu. Bir mikroservis kendi veritabanına sahip olmalı. İki servis sürekli birbirinin verisini API üzerinden veya paylaşılan veritabanlarından okumak zorundaysa, dağıtık monolit inşa etmişsiniz demektir — mikroservislerin tüm operasyonel karmaşıklığı, hiçbir faydası olmadan.

Domain modeliniz gerçekten ayrılabilirse (örneğin faturalama envanterle hiç ilişkili değilse), mikroservis size temiz sahiplik verebilir. Her şey her şeyle iç içeyse (tek, yoğun bağlantılı bir kullanıcı/sipariş/ürün grafiği), monolit kalmak daha hızlıdır.

4. Hata izolasyonu

Mikroservis bir hatayı kontrol altına almanıza izin verir: öneri servisi çökerse, ödeme akışı hâlâ çalışır. Bu gerçek bir değer — eğer gerçekten ihtiyacınız varsa.

Çoğu kurumsal iç uygulama için, deployment sırasında uygulamanın 90 saniye boyunca down olması iş kritik bir acil durum değildir. Dakika başına gelir riski olan tüketici platformları için ise öyledir.

5. Operasyonel karmaşıklık toleransı

Mikroservis şunlara ihtiyaç duyar: service mesh veya muadili, distributed tracing, merkezi loglama, contract testing, çoklu cluster orkestrasyonu ve bu servislerin çalıştığı altyapıyı sahiplenen bir platform takımı. Bu platform takımı tipik olarak 2–4 kıdemli mühendis — başka hiçbir şey değil, sadece ürün takımlarını yetkilendiren.

Bu operasyonel katmana sahip değilseniz veya sahip olmak istemiyorsanız, mikroservis sizi yakar.

Soru asla "monolit mi mikroservis mi" değildir. "Hangi tür bağımsızlık karşılığında ne kadar operasyonel karmaşıklığı emmeye razıyız?" sorusudur.

Hangi pattern ne zaman kazanır

Beş eksenden geçtikten sonra resim genellikle netleşir.

Şu durumlarda monolit kalın

• Mühendislik organizasyonunuz 30 kişinin altında
• Ürün makul şekilde birlikte deploy oluyor
• Domain modeliniz yüksek bağlantılı
• Adanmış bir platform takımınız yok
• Önümüzdeki 12 aylık yol haritası için time-to-market'i optimize ediyorsunuz

Şu durumlarda mikroservise geçin

• Gerçek bağımsızlığa ihtiyaç duyan birden fazla takımınız var
• Ürünün farklı parçaları çok farklı deployment, ölçekleme veya uyumluluk gereksinimlerine sahip
• Operasyonel araçlara adanmış bir platform takımı ayırabiliyorsunuz
• Deployment çakışması ve entegrasyon test acısına çoktan ulaştınız
• Sert servis seviyesi izolasyon gereksinimleriniz var (regülasyonlu bölgeler, çok kiracılı blast-radius kısıtları)

Modüler monolit — orta yol

50–500 çalışan aralığındaki çoğu kurumsal ekip için 2026'da doğru cevap ne saf mikroservis ne de tek başına yayılan bir monolit. Modüler monolit: tek deployable, ama içeride sınırlı modüllere ayrılmış ve aralarında açık arayüzler olan.

Bu, Internative olarak en sık önerdiğimiz mimari. Size verdiği:

• Tek deployment hattı (ucuz, hızlı)
• Açık modül sınırları (refactoring güvenliği, gelecekte ayırma opsiyonu)
• Tek veritabanı, ancak modül sahipli şemalar
• Bir modülün deployment hızı veya ölçekleme profili gerçekten ayrıştığında, ileride gerçek bir mikroservis çıkarma yolu

Modüler monolit sweet spot çünkü ayırma opsiyonunu koruyor — operasyonel maliyeti baştan ödetmeden.

Gerçek dünyadan referans noktaları

Trendyol mikroservis mi kullanıyor?

Türkiye'nin önde gelen e-ticaret platformları — Trendyol, Hepsiburada, Getir — tamamen mikroservis tabanlı çalışıyor. Ancak gözden kaçan detay şu: bu şirketler operasyonel olarak dakika başına gelir riski taşıyor ve her birinin yüzlerce mühendisten oluşan platform organizasyonları var. Mimarileri ölçeklerinde ve gelir modellerinde mantıklı. 100 kişilik bir kurumsal yazılım şirketi için neredeyse hiç faydalı bir referans noktası değil.

Netflix nasıl?

Netflix kanonik "biz mikroservise geçtik" hikayesi — ancak gerçeklik daha nüanslı. Netflix yüzlerce servise sahip, bunları binlerce container üzerinde çalıştırıyor ve mikroservisi yaşanabilir kılmaya adanmış önemli ölçekte bir platform takımı var. Cevapları onların ölçeğinde ve gelir maruziyetinde anlamlı. Çoğu kurumsal Türk şirketi için doğrudan kopyalanabilir bir model değil.

Erken kırma — en yaygın anti-pattern

En sık gördüğümüz hata: 25 kişilik bir mühendislik takımı, erken monolitlerini 12 servise ayırıyor, her biri (ismen) 2 mühendis tarafından sahiplenilen. Altı ay sonra 12 deployment hattına, servisleri kapsayan entegrasyon testlerinin olmamasına, kesişen sorunlar için kırılgan bir paylaşılan kütüphaneye ve sıfır kişilik bir platform takımına sahipler. Orijinal monoliti yeniden yaratmışlar — dağıtık, debug etmesi daha zor ve hız kazanımı yok.

Erken kırmayın. Önce modülerleştirin, deployment acısını gözlemleyin, sonra çıkarın.

2026 kurumsal CTO'lar için karar çerçevesi

Herhangi bir mimari karardan önce, dürüstçe cevaplanması gereken dört soru:

1. 18 aylık takım gidişatımız ne? 20'den 60 mühendise mi gidiyor? Modüler monolit. 80'den 250'ye mi? Muhtemelen hak eden parçalarda mikroservis.
2. Bugün deployment acımız ne? Deployment'lar 10 dakika ve çakışmasızsa, çözmeniz gereken bir mikroservis sorunu yok. Deployment'lar 2 saat sürüyorsa ve özellik yayınları test stabilitesine bağlıysa, kanıtınız var.
3. Platform katmanını kim sahipleniyor? Cevap "herkes" veya "kimse" ise mikroservis başarısız olacak. Ya bir platform takımı ayırın ya da modüler kalın.
4. 90 saniye down olmanın maliyeti ne? Maddi bir şey değilse, operasyonel maliyeti haklı kılacak kadar hata izolasyonuna ihtiyacınız yok.

İlgili okumalar

Kararınız backend modülerliğinden çok mobil mimariye yakınsa, React Native vs Flutter Kurumsal Mobil Karar Rehberi yazımız mobil stack'ler için aynı paralel soruyu işliyor. Her iki mimariye AI eklemeyi düşünen takımlar için Kurumsal Yazılımda Yapay Zeka Entegrasyonu yazımız üretimde en çok ship ettiğimiz beş pattern'ı detaylandırıyor.

Nasıl yardımcı oluyoruz

Internative olarak her iki mimari biçimde engagement'lar yürütüyoruz — ilk düzgün backend'lerini standartlaştıran scale-up'lar için modüler monolit, monolitlerinden büyüyen takımlar için dikkatli mikroservis çıkarmaları ve erken kırılan takımları konsolide etmek isteyen de-microservice projeleri.

Tipik engagement'imiz: 2–5 kişilik kıdemli pod, 3–6 ay, TR saat dilimi, 350 USD/uzman/gün, şeffaf ve aracısız. Önce mimari denetim ile başlıyoruz, kararı birlikte veriyoruz, sonra implementasyonu hayata geçiriyoruz.

Bu soruyu kendi takımınız için tartıyorsanız, tech lead'imizle 15 dakikalık bir mimari değerlendirme görüşmesi, bir ay daha iç tartışmadan daha net bir cevap verir. Veya yazılım mühendisliği vaka çalışmalarımıza benzer şekiller için göz atabilirsiniz.

Doğru mimari, takımınızın bugün iyi işletebileceği ve yarın temiz bir şekilde evriltebileceği mimaridir. Bu neredeyse hiç bir doktrin değildir — beş somut eksen üzerinde bilinçli bir tercihtir.