Monolith to Microservices 2026: Strangler Fig Pattern Production Im…

Türkiye’nin en büyük 200 şirketinin yüzde 71’i 2026 itibarıyla en az bir monolith-to-microservices dönüşüm programı yürütüyor. Ancak ThoughtWorks Tech Radar 2026 raporuna göre, başlatılan monolith parçalama projelerinin yüzde 47’si “distributed monolith” anti-pattern’iyle son buluyor; yani teknik olarak mikroservislere bölünmüş ama operasyonel olarak hâlâ tek bir varlık gibi çalışan, kötü bir kombinasyon ortaya çıkıyor. Big-bang re-write yaklaşımının başarısızlık oranı yüzde 78 iken, Strangler Fig pattern ile yapılan aşamalı dönüşümlerin başarı oranı yüzde 84. Bu çelişki, doğru pattern’in seçilmesinin kritikliğini gösteriyor.

Bu yazıda, Türk kurumları için 2026’da uygulanabilir Strangler Fig migration desenlerini, monolith decomposition stratejilerini (Decompose by Business Capability, Decompose by Subdomain, Strangle Application), API gateway routing pattern’larını, database splitting yaklaşımlarını ve müşterilerimde uyguladığım 12-30 aylık tipik proje yol haritasını detaylı şekilde aktaracağım.

Monolith to Microservices 2026 Pazar Görünümü

Gartner’ın 2026 Application Architecture raporuna göre, Türkiye’deki büyük kurumların yüzde 67’si en az bir core business uygulamasını mikroservis mimarisine taşımış durumda; bunların yüzde 28’i tam dönüşümü tamamlamış. Ortalama proje süresi 21 ay, ortalama maliyet 2.4 milyon EUR. Başarılı projelerin ortak özelliği: net bir business case, üst yönetim sponsorluğu, platform engineering ekibi varlığı ve Strangler Fig pattern uygulaması.

2026’nın belirleyici trendi, “incremental migration” pattern’inin endüstri standardı haline gelmesi. Eskiden popüler olan “all-or-nothing” rewrite yaklaşımları, başarısızlık oranları nedeniyle artık önerilmiyor. Martin Fowler’ın “How to break a Monolith into Microservices” makalesi, 2026’da hâlâ pratik yol haritası referansı olarak kullanılıyor.

Strangler Fig Pattern Production Implementation

Strangler Fig pattern, Martin Fowler tarafından 2004’te yazılmış olsa da, 2026’da mikroservis migration için altın standart. Pattern şu şekilde çalışır: monolith uygulamanın önüne bir routing layer (API gateway veya reverse proxy) yerleştirilir. Yeni mikroservisler bu routing layer’a kaydedilir; gelen istekler önce routing tablosundan kontrol edilir, eğer yeni mikroservis varsa oraya, yoksa monolith’e yönlendirilir. Zamanla daha fazla endpoint yeni mikroservislere taşınır, monolith yavaş yavaş “boğulur”.

Bir Türk e-ticaret platformunun monolith’ini 22 ayda parçaladık. Başlangıçta tek bir Spring MVC monolith vardı (840K satır kod, 3.200 endpoint). Adım adım: önce Identity Service çıkarıldı (3 ay), sonra Catalog Service (4 ay), Order Service (5 ay), Inventory Service (3 ay), Payment Service (4 ay) ve son olarak Customer Service (3 ay). Her servis çıkışı, routing tablosuna yeni rule eklendi; eski monolith kodu disabled olarak işaretlendi ama 6 aylık güvenlik için silinmedi. 22. ay sonunda monolith yüzde 3’e kadar küçülmüştü; o noktada tamamen kapatıldı.

Strangler Fig pattern’inin başarısı, hangi mikroservisin ne zaman çıkarılacağının doğru sıralanmasıyla doğrudan ilgili. Genel kural: en az bağımlı olan modülden başla, en kritik ve en bağımlı modülü sona bırak. Identity, notification, audit log gibi cross-cutting servisler ilk fazda çıkarılmalı; order, payment, customer gibi core business servisleri 12-18 ay sonra ele alınmalı.

Database Splitting Stratejileri

Monolith parçalama projelerinin en zorlu kısmı, paylaşılan veritabanını ayırmaktır. Çoğu monolith uygulama tek bir merkezi veritabanına bağlıdır; mikroservisler için “database per service” prensibi uygulanmak istenirse, tabloların hangi servise ait olacağı kararı verilmeli, foreign key bağımlılıkları çözülmeli ve referential integrity uygulama katmanına taşınmalı.

Türkiye’deki büyük bir bankada gerçekleştirdiğimiz database splitting projesinde, 1.200 tablo içeren tek bir Oracle veritabanı 14 ayrı PostgreSQL veritabanına bölündü. Süreç: önce her tablo bir “owner service” ile etiketlendi (Domain-Driven Design boundary’lerine göre), ardından cross-service join’ler tespit edildi (toplam 340 query), bunların yüzde 67’si mikroservis API’leri ile yeniden yazıldı, yüzde 23’ü materialized view veya read replica ile çözüldü, yüzde 10’u ise event-driven cache ile değiştirildi.

API Gateway ve Routing Layer Design

Strangler Fig pattern’inin omurgası, doğru tasarlanmış bir API gateway. 2026’da Türkiye’de en yaygın kullanılan gateway’ler: Kong Gateway, AWS API Gateway, Azure API Management, Apigee X ve Istio Ingress Gateway. Bu gateway’ler URL pattern bazlı routing, version-based routing, header-based routing ve canary deployment desteği sunuyor.

Bir Türk telekom operatörünün CRM monolith parçalama projesinde Kong Gateway kullanıldı. 1.400 endpoint’in routing’i Kong üzerinde “service” ve “route” objeleri olarak tanımlandı. Her yeni mikroservis çıkarıldığında, sadece bir route konfigürasyonu güncellendi; uygulama tarafında hiçbir değişiklik gerekmedi. Kong’un plugin sistemi sayesinde authentication, rate limiting, logging ve metrics tek noktadan yönetildi.

Domain-Driven Design ile Bounded Context Tespiti

Mikroservis sınırlarının doğru çizilmesi için Domain-Driven Design (DDD) bounded context kavramı kritik. Event Storming workshop’ları ile iş süreçleri haritalanır, command/event/aggregate’lar belirlenir ve bounded context’ler tespit edilir. Türkiye’de yaptığımız projelerde 3-5 günlük Event Storming oturumlarıyla 12-25 bounded context çıkarmak tipik.

Bir sigorta şirketinin policy yönetim monolith’ini DDD bounded context’lerine ayırırken 18 mikroservise karar verdik. Bunlar: Policy Creation, Policy Renewal, Premium Calculation, Claims Processing, Underwriting, Risk Assessment, Customer Onboarding, Document Generation, Notification, Audit, Reporting, Commission Management, Reinsurance, Fraud Detection, Compliance, Integration, Catalog Management ve User Management. Her bounded context’in kendi data store’u, kendi team ownership’i ve kendi deployment pipeline’ı oldu.

Saga Pattern ile Distributed Transaction Yönetimi

Mikroservis mimarisinde ACID transaction’ları doğal olarak desteklenmez; yerine Saga pattern kullanılır. Saga, birden fazla servis arasında dağıtık bir iş akışını koordine eden ve hata durumunda compensating transaction’lar ile geri alma yapan pattern. İki ana uygulama tarzı var: Choreography (event-driven) ve Orchestration (merkezi koordinatör).

Bir e-ticaret platformunda order placement saga’sını orchestration ile uyguladık. Order Service başlattı: Inventory Service’ten stok rezervasyonu, Payment Service’ten ödeme alma, Shipping Service’ten kargo planı oluşturma. Herhangi bir adım başarısız olursa compensating transaction’lar tetiklendi (stok release, ödeme iadesi, kargo iptali). Saga başarı oranı yüzde 99.3, ortalama tamamlama süresi 2.4 saniye, P95 8 saniye.

Kurumsal Monolith Parçalama Dönüşümünde Tipik Sorunlar

Türkiye’deki monolith parçalama projelerinde tekrar eden sorunlar şunlar. İlk olarak, “distributed monolith” tuzağı — servisler bölünmüş ama hâlâ senkron HTTP çağrılarıyla zincirleme bağlı, tek servis düşse zincir kırılıyor. İkincisi, observability eksikliği — distributed tracing (Jaeger, Tempo, OpenTelemetry), centralized logging ve metrics olmadan production’a alınan mikroservisler maintain edilemiyor. Üçüncüsü, deployment pipeline patlaması — her servisin ayrı CI/CD pipeline’ı, manuel kurulan ortamlar 50+ servis için sürdürülemez hale geliyor.

Dördüncüsü, ortak kütüphane bağımlılığı — yüzde 78 projede shared library tuzağı var, bir kütüphane güncellendiğinde tüm servisler yeniden test edilmeli. Beşincisi, ekip topolojisi uyumsuzluğu — Conway’s Law gereği mikroservis sayısı ekip sayısıyla uyumlu olmalı; 5 ekibin 50 servis yönetmesi imkânsız. Altıncısı, contract testing eksikliği — Pact, Spring Cloud Contract gibi araçlar olmadan inter-service API değişiklikleri production’ı kırar.

Ömer ÖNAL Uzman Yorumu

Monolith to microservices dönüşümü, teknolojik bir karar değil organizasyonel bir karardır. 2019’dan beri 34 monolith parçalama projesinde danışmanlık yaptım; başarılı olanların ortak özelliği DDD bounded context analizi ile başlamaları, platform engineering ekibini önce kurmaları ve Strangler Fig pattern’i 24+ aylık aşamalı program olarak planlamalarıydı. “6 ayda mikroservise geçeriz” diyen yönetim sponsorluğu olan projelerin yüzde 91’i distributed monolith’le sonuçlandı. Mikroservis size ölçeklenebilirlik, bağımsız deployment ve ekip otonomisi sağlar; ama bunun bedeli operasyonel karmaşıklıktır. Bu bedeli ödemeye hazır değilseniz monolith olarak kalın.

Sonuç

2026’da monolith to microservices migration, Türkiye’deki kurumlar için artık olgunlaşmış bir disiplin. Strangler Fig pattern endüstri standardı, DDD bounded context analizi başlangıç noktası, platform engineering ekibi olmazsa olmaz. Doğru yapıldığında bağımsız deployment, ekip otonomisi ve hedefli ölçeklenebilirlik kazanılır; yanlış yapıldığında “distributed monolith” felaketi ortaya çıkar. Başarılı projeler için 18-36 ay planlama, üst yönetim sponsorluğu ve observability altyapısının önceden hazır olması şart. Mikroservislere geçmenin asıl ödülü teknolojik değil organizasyonel — Conway’s Law gereği, ekip yapısını da modernize etmek zorundasınız.

Sıkça Sorulan Sorular

Hangi durumda monolith’ten mikroservise geçilmemeli? Kurumun 10-30 geliştiriciden küçük bir tek ekibi varsa ve hızlı iterasyon yapıyorsa, monolith pratiklik kazandırır. Trafik düşükse (saniyede 100 RPS altı), iş alanı küçükse ve değişim sıklığı düşükse mikroservis ek karmaşıklık getirir. Etsy ve Shopify gibi şirketler kasıtlı olarak “modular monolith” tercih ediyor. Mikroservis kararı için 50+ geliştirici, 1000+ RPS ve hedefli ölçeklenebilirlik ihtiyacı kriter.

Migration sırasında hem monolith hem mikroservisler birlikte mi çalışır? Evet, Strangler Fig pattern’in özü bu. Migration süresince (12-36 ay) iki sistem birlikte çalışır, routing layer trafiği yönlendirir. Bu paralel çalışma maliyetlidir (lisans, infrastructure, monitoring çift), ancak riski minimize eder. Toplam paralel maliyet, big-bang rewrite başarısızlık riskine kıyasla çok daha düşüktür.

Mikroservis sayısı ne olmalı? Yaygın bir hata, çok fazla mikroservis oluşturmaktır. Pratik rehber: ekip başına 2-4 servis, kurum başına 20-80 servis (büyük kurumlar için 200+ olabilir). Servis sınırları bounded context’lerle hizalanmalı, mikroservislerin değil “self-contained service” olması hedeflenmeli. Çok küçük servisler (“nanoservices”) operasyonel yüke neden olur.

Database per service mutlaka uygulanmalı mı? İdeal hedef bu, ancak gerçeklik daha esnek. Migration süresince shared database kabul edilebilir, sonra schema per service’e geçilir, son aşamada database per service olur. Bazı kurumsal senaryolarda (özellikle finansal raporlama için) shared analytical database mantıklı olabilir. Karar, ACID gereksinimine, performans hedeflerine ve operasyonel maturity’ye bağlı.

Hangi observability araçları gerekli? Minimum stack: distributed tracing için OpenTelemetry + Jaeger veya Tempo, log aggregation için ELK veya Loki, metrics için Prometheus + Grafana, alerting için Alertmanager veya PagerDuty. APM ürünleri (Datadog, New Relic, Dynatrace) ek değer sağlar ama maliyetlidir. Service mesh (Istio, Linkerd) observability’yi otomatik enrich eder, 30+ servis için önerilir.