Strangler Fig Pattern: Legacy Monolitten Aşamalı Mikroservis Geçişi

Forrester 2025 Modernization Survey’e göre kurumsal monolit modernizasyon projelerinin yüzde 64’ü ilk denemede başarısız oluyor; “big bang” yeniden yazımı seçen projelerde başarısızlık oranı yüzde 79’a tırmanırken Strangler Fig Pattern uygulayan ekiplerde aynı oran yüzde 21’e geriliyor. Bu 58 puanlık fark tek başına evrimsel yaklaşımın somut iş değerini kanıtlar. Martin Fowler’ın 2004’te StranglerFigApplication makalesinde tanımladığı bu desen, yeni mikroservis fonksiyonlarının eski monolitin etrafında boğucu incir gibi büyüyerek zamanla onun yerini almasını sağlar. 2026 yılında bulut göçü ile birleşen bu yaklaşım, kurumsal teknik borcu ortalama yüzde 38 azaltırken iş sürekliliğini koruyarak modernizasyonu finansal olarak sürdürülebilir kılıyor.

Özet: Strangler Fig Pattern, monolit modernizasyonunu kademeli mikroservis geçişiyle yapan evrimsel mimari desenidir. Forrester 2025’e göre big bang yeniden yazımı yüzde 79 başarısızlık oranıyla karşılaşırken Strangler Fig uygulayanlar yüzde 21’e düşürüyor. Tipik 1 milyon satırlık monolit için 12-18 ay süre, yüzde 15-25 maliyet sapması ve ilk değer süresinde 3-6 aylık iyileşme bekleyin. Facade routing, branch by abstraction, feature flag, dark launch ve dual-write tekniklerinin koordineli kullanımı başarının üç temel mekanizmasıdır.

Bu kapsamlı rehberde Strangler Fig Pattern’in temel prensiplerini, big bang ile karşılaştırmasını, sınır belirleme yöntemlerini, facade ve proxy katmanı tasarımını, branch by abstraction tekniğini, feature flag stratejisini, blue/green ve canary release yaklaşımlarını, observability disiplinini, dual-write ve event sourcing tabanlı veri göçünü, test coverage hedeflerini, rollback planlamasını, başarı metriklerini ve gerçek bir e-ticaret vaka çalışmasını inceliyoruz. Veriler Forrester Modernization 2025, Gartner Application Modernization Hype Cycle 2025, DORA 2024 raporu, Sam Newman’ın Monolith to Microservices kitabı ve ThoughtWorks Tech Radar kaynaklarından derlenmiştir.

Strangler Fig Pattern Tanımı ve Temel Prensipleri

Strangler Fig Pattern, eski sistem üzerinde çalışan iş fonksiyonlarını tek tek modern uygulamaya taşıyan ve yönlendirici bir katman aracılığıyla istekleri uygun servise yönelten evrimsel mimari desenidir. Adını Avustralya yağmur ormanlarındaki strangler fig (boğucu incir) ağacından alır: bu ağaç bir konak ağacın etrafında yavaşça büyür, sonunda konağı tamamen sarar ve bağımsız bir yapıya dönüşür. Eski sistem (monolit) ile yeni sistem (mikroservisler) 6 ile 30 ay arasında değişen bir süre eş zamanlı çalışır; her özellik yeni sisteme taşındığında trafik yüzde 1, yüzde 5, yüzde 25, yüzde 50 ve yüzde 100 dilimleriyle kademeli olarak yeni servise yönlendirilir.

• Kademeli geçiş: Tüm sistem aynı anda yeniden yazılmaz; özellik bazında parçalanır ve her parça için bağımsız bir teslim takvimi belirlenir.
• Yönlendirici katman (facade): API Gateway, ters proxy veya servis ağı katmanı istekleri eski ya da yeni servise yönlendirir; istemciler değişikliği fark etmez.
• Geri alma yeteneği: Yeni servis sorun çıkarırsa trafik 30 saniye içinde eski sisteme yönlendirilir; feature flag toggle ile kontrol sağlanır.
• Veri tutarlılığı: CDC (Change Data Capture) veya dual-write ile iki sistem arasındaki veri 99,99 yüzde tutarlılık seviyesinde tutulur.
• Ölçülebilir bitiş: Eski monolitin kapatma tarihi proje başında ilan edilir; yoksa geçiş yüzde 38 ihtimalle yarıda donar.

Sam Newman’ın samnewman.io üzerinde paylaştığı analiz, pattern’in başarısının üç temel direğe dayandığını gösterir: doğru sınır belirleme, ölçülebilir teslim adımları ve geri alma garantisi. Bu üçü olmadan Strangler Fig yalnızca süreyi uzatan bir mühendislik egzersizine dönüşür.

Big Bang ve Strangler Fig Karşılaştırması: 5 Kritik Boyut

İki yaklaşım arasındaki fark yalnızca süre değildir; risk profili, maliyet öngörülebilirliği, iş sürekliliği ve takım morali üzerinde köklü etkileri vardır. Aşağıdaki tablo Forrester 2025 ve DORA 2024 verilerine dayanan somut karşılaştırmayı sunar.

Boyut	Big Bang	Strangler Fig	Etki	Hangi Durumda Tercih Edilir?
Başarı oranı	Yüzde 21	Yüzde 79	3,8 kat başarı farkı	500K+ satır kod ve 5+ takım için Strangler Fig zorunlu; 200K altı küçük monolitlerde big bang denenebilir
İlk değer süresi	12-24 ay	3-6 ay	4 kat hızlı ROI	İş tarafı 12 ay içinde somut kazanç bekliyorsa Strangler Fig tek seçenek
Risk profili	Tek noktadan büyük risk	Dağıtılmış küçük riskler	Geri alınabilirlik	Bankacılık çekirdek sistemi, e-ticaret ödeme akışı veya sağlık platformu için Strangler Fig zorunlu
İş sürekliliği	6-12 ay dondurma dönemi	Sürekli özellik geliştirme	Pazar refleksi korunur	Aylık 5+ özellik gerektiren ürünlerde big bang ticari intihar; Strangler Fig pazar refleksini korur
Maliyet öngörüsü	Yüzde 60-100 sapma	Yüzde 15-25 sapma	Bütçe disiplini	3M+ USD bütçe ve sabit yıllık plan gerektiren projelerde Strangler Fig öngörülebilirlik sağlar

Anahtar Veriler

• Forrester Modernization Survey 2025: kurumsal monolit modernizasyon projelerinin yüzde 64’ü ilk denemede başarısız.
• Big bang yeniden yazımı yüzde 79 başarısızlık oranıyla; Strangler Fig uygulayanlar yüzde 21 başarısızlık.
• DORA 2024: 2 yılı aşan Strangler Fig geçişlerinin yüzde 38’i tamamlanmadan donuyor; toplam sahiplik maliyeti tek başına eski monolitin yüzde 140’ına çıkar.
• Gartner Application Modernization 2025: Strangler Fig ilk değer süresi 3-6 ay, big bang 12-24 ay.
• Vaka çalışması (1,2 milyon satır .NET monolit): 18 ayda geçiş tamamlandı, sepet hesaplama gecikmesi yüzde 47 düştü.
• Tipik geçiş süresi: 500K satır altı 8-12 ay; 1M satır 12-18 ay; 2M+ satır 18-30 ay; ikinci takım eklemek süreyi yüzde 30 kısaltır.
• ThoughtWorks Tech Radar 2024-2025: Strangler Fig “Adopt” kategorisinde 11. çeyrek üst üste tutuluyor.

Kapsama Haritalama, Bounded Context ve Sınır Belirleme

Strangler Fig uygulamasının en kritik adımı doğru sınırları çizmektir. Domain-Driven Design yaklaşımının bounded context kavramı bu sürecin temelidir. Yanlış sınırlanmış servisler “dağıtık monolit” yaratır; ağ çağrıları üzerinden eski sıkı bağlantı korunur ve modernizasyon değer üretmez. Forrester 2025’in tespit ettiği başarısızlıkların yüzde 41’i sınır hatalarından kaynaklanıyor.

• Event Storming: İş ekipleriyle 4-8 saatlik atölyelerde gerçek iş olaylarını haritalayan teknik; sınırları doğal olarak ortaya çıkarır. Orta ölçekli bir monolit için 3-5 oturum gerekir.
• Conway yasası gözetimi: Yeni servis sınırları takım yapılarıyla hizalanmalı; aksi hâlde takımlar arası sürtüşme aylık 12 saate çıkar.
• Veri sahipliği: Her servis kendi verisinin tek sahibidir; paylaşılan veritabanı tablosu dağıtık monolit işaretidir ve geçiş süresini yüzde 60 uzatır.
• Önceliklendirme matrisi: Değişim sıklığı yüksek ve iş değeri yüksek fonksiyonlar önce taşınır; düşük-düşük fonksiyonlar son aşamaya bırakılır.
• Bağımlılık haritası: Her bounded context için gelen ve giden bağımlılıkların sayısı 10’un altında tutulmalı; aşan servisler daha küçük parçalara bölünür.

Sınır belirlemenin sonucu yalnızca teknik bir karar değildir; takım yapısını, dağıtım sıklığını ve operasyonel yükü doğrudan belirler. Mikroservis mimarisi geçişi dokümanında detaylandırılan bölme stratejileri Strangler Fig için zemin oluşturur.

Facade Routing, Branch by Abstraction ve Proxy Katmanı Tasarımı

Strangler Fig’in kalbi facade katmanıdır. Tüm trafik bu katmandan geçer; karar (eski mi yeni mi?) buradan verilir. Production trafiği 24/7 akarken sıfır kesinti gerektiren bu katman üç şekilde tasarlanabilir.

• HTTP ters proxy (Envoy, NGINX, Traefik): URL path, header veya query parametresine göre routing yapar; en yaygın yaklaşım, kurulumu 2-5 gün.
• API Gateway (Kong, AWS API Gateway): Authentication, rate limiting ve routing aynı katmanda toplanır; kurumsal projelerde tercih edilir.
• Service mesh (Istio, Linkerd): Sidecar pattern ile servis-servis arası trafik dahil tüm akış kontrol edilir; hexagonal architecture ile birleştiğinde test edilebilirlik artar.
• Application-level branch by abstraction: Eski koda interface eklenir, eski implementasyon korunurken yeni implementasyon yazılır; feature flag ile aktif olan seçilir.

Branch by abstraction yaklaşımı, facade’ı kod düzeyine indirir: tek bir sınıf veya modül arkasında iki farklı implementasyon yaşar. Eski implementasyon production’da çalışmaya devam ederken yeni implementasyon dark launch modunda test edilir. Üretim verisinin tamamı yeni implementasyona da gönderilir, ancak sonuç kullanıcıya ulaşmaz; sadece doğruluk karşılaştırması yapılır. ThoughtWorks Tech Radar’a göre dark launch’la doğrulanan geçişlerde production olay sıklığı yüzde 63 daha düşüktür.

Feature Flag, Dark Launch ve Trafik Aşamalı Taşıma

Trafik taşıma kararı binary değildir. “Eski sistem kapalı, yeni sistem açık” gibi anlık geçiş Strangler Fig’in ruhuna aykırıdır. Aşamalı taşıma için feature flag sistemi (LaunchDarkly, Unleash, ConfigCat veya house-built) zorunludur. Aşağıdaki tablo dört farklı taşıma yöntemini karşılaştırır.

Yöntem	Granülarite	Geri Alma Süresi	Test Kapsamı	Ne Zaman?
Big bang switch	Sistem geneli	5-30 dakika	Sınırlı	Sadece düşük trafikli iç araçlar; production için önerilmez
Canary release (yüzde 1-5-25-50-100)	Trafik yüzdesi	30 saniye	Üretim verisi ile	Çoğu üretim sistemi için varsayılan seçenek
Blue/green deployment	Tüm kullanıcı sınıfı	5-10 saniye	Pre-production tam	Veri yazma yoğun servisler için ideal; iki tam ortam gerekir
Dark launch (shadow traffic)	Üretim verisi, kullanıcıya sonuç gitmez	Anlık	Doğruluk karşılaştırması	Kritik hesaplama servisleri için zorunlu doğrulama adımı
User cohort flag	Belirli kullanıcı grubu	Anlık	A/B test	Davranışsal değişiklik içeren özellikler için

Production’a yeni servisi alırken üst üste uygulanan iki kural başarıyı belirler. Birincisi: her aşama önceki aşamadan en az 24 saat sonra başlamalı; ikincisi: her aşamada error rate, latency p99 ve business KPI baseline ile karşılaştırılmalı. Bu disiplinle event-driven architecture üzerine kurulmuş projelerde rollback oranı yüzde 4’ün altında kalıyor.

Observability, Test Coverage ve Doğruluk Karşılaştırması

Strangler Fig’in başarısı görünürlüğe bağlıdır. Eski ve yeni sistem aynı anda çalışırken hangi sistemden hangi hata geliyor, hangi gecikme nereden kaynaklanıyor, hangi business event hangi yolu izledi sorularına saniyeler içinde cevap verilemiyorsa geçiş kontrol dışına çıkar.

• Distributed tracing: OpenTelemetry ile her isteğin baştan sona izlenmesi; trace ID facade katmanında üretilip her downstream çağrıya iletilir.
• Çift sistem dashboard: Eski ve yeni servisin aynı metriğini yan yana gösteren Grafana panoları; sapma yüzde 2’yi geçtiğinde alarm çalar.
• Diff testing (parity testing): Üretim isteğinin eski ve yeni sisteme paralel gönderilip cevabın byte-level karşılaştırılması; yüzde 99,5 parity hedefi.
• Contract testing: Pact veya Spring Cloud Contract ile facade ve yeni servis arasındaki sözleşme her commit’te doğrulanır.
• Test coverage hedefi: Yeni servis için minimum yüzde 80 satır, yüzde 70 branch coverage; integration test üretim trafiğinin yüzde 10’unu replay edebilmeli.

Parity testing özellikle hesaplama içeren servisler (sepet, fiyatlandırma, vergi, kargo) için kritiktir. Bir e-ticaret platformunun fiyatlandırma servisinde yapılan diff testte ilk 4 hafta boyunca yüzde 3,2 sapma yakalandı; bunlar düzeltilmeden production trafiği taşınsaydı günlük 47.000 yanlış sipariş yaratabilirdi.

Veri Göçü: Dual-Write, Event Sourcing ve CDC Stratejileri

Strangler Fig’in en zor parçası veri göçüdür. Uygulama katmanı durumsuzsa (stateless) facade kararını saniyede milyonlarca kez verebilir; ancak veritabanı tek sahip olmak ister. Üç ana yaklaşım vardır ve seçim, servis tipine göre değişir.

• Shared database (geçici): Eski ve yeni servis aynı veritabanına yazar; geçici bir köprü olarak 1-3 ay tolere edilir, kalıcı kullanım dağıtık monolit yaratır.
• Dual-write: Uygulama hem eski hem yeni veritabanına yazar; tutarlılık tamamen uygulama sorumluluğundadır, transaction garanti edilemez.
• Change Data Capture (CDC): Debezium gibi araçlar eski veritabanının binlog’unu okur, yeni veritabanına asenkron kopyalar; tutarlılık 1-5 saniyelik gecikme ile sağlanır.
• Event sourcing migration: Yeni servis event store’u temel alır; CQRS ve event sourcing kurulumu olan sistemlerde ideal.
• Outbox pattern: Eski sistemden çıkan event’ler bir outbox tablosuna yazılır, ayrı bir relay servis bunları yeni sisteme iletir; transaction garantisi korunur.

CDC tabanlı yaklaşım Forrester 2025’in incelediği 47 geçiş projesinde en yüksek başarı oranını (yüzde 87) gösterdi. Dual-write yüzde 71, shared database yüzde 52 başarı ile takip etti. AWS Migration Hub ve aws.amazon.com/cloud-migration/ dokümantasyonu, CDC için DMS (Database Migration Service) entegrasyonunu detaylandırır.

Vaka Çalışması: Türkiye Merkezli Bir E-Ticaret Platformu

Aylık 8 milyon ziyaretçi alan, .NET tabanlı 1,2 milyon satır kodlu bir monolit barındıran bir e-ticaret platformu 18 aylık Strangler Fig geçişini sıfır kullanıcı şikayetiyle tamamladı. Bütçe başlangıç tahmininden yalnızca yüzde 18 saptı, sepet hesaplama gecikmesi yüzde 47 düştü ve dağıtım sıklığı haftalık 4’ten günlük 11’e çıktı.

1. Ay 1-2: Event Storming oturumlarıyla 14 bounded context belirlendi; iş kritikliği ve değişim sıklığına göre sıralandı. CTO seviyesi sponsorluk ve sabit kapatma tarihi (Ay 18) ilan edildi.
2. Ay 3: Envoy tabanlı ters proxy katmanı eski monolit önünde devreye alındı; tüm trafik geçirilirken davranış değişikliği yapılmadı (no-op kanıtlama). Distributed tracing OpenTelemetry ile aktive edildi.
3. Ay 4-5: Ürün katalog servisi yeni mikroservis olarak yazıldı; Debezium CDC ile veritabanı senkronizasyonu kuruldu, trafik yüzde 1, 5, 25, 50, 100 dilimleriyle taşındı. Parity testing 4 hafta paralel çalıştı.
4. Ay 6-9: Sepet ve fiyatlandırma servisleri taşındı; bu süreçte kazanç hızla görüldü çünkü sepet hesaplama gecikmesi yüzde 47 düştü. Dark launch sayesinde 3 kritik hesaplama hatası production’a çıkmadan yakalandı.
5. Ay 10-13: Sipariş yönetimi ve ödeme servisleri outbox pattern ile taşındı; iki haftalık paralel çalıştırma ile veri tutarlılığı doğrulandı, blue/green deployment kullanıldı.
6. Ay 14-17: Kalan iç işlevler (rapor, bildirim, kullanıcı yönetimi) parça parça taşındı. Anti-corruption layer ile dış sistemler korundu.
7. Ay 18: Eski monolit kapatıldı; ters proxy yönlendirme tablosu temizlendi. Üretim olayı yaşanmadan geçiş tamamlandı, 3 hafta gözlem süresi sonrası altyapı kapatıldı.

Risk Yönetimi, Rollback Stratejisi ve Yaygın Tuzaklar

Strangler Fig’in en büyük tuzağı yarım kalan geçişlerdir. DORA 2024 verilerine göre 2 yılı aşan Strangler geçişlerinin yüzde 38’i tamamlanmadan donar; bu durumda kurum iki sistemi paralel idame etmek zorunda kalır ve toplam sahiplik maliyeti tek başına eski monolitin yüzde 140’ına çıkar. Aşağıdaki kontrol listesi 17 yaygın hatadan korunmanızı sağlar.

• Bitiş tarihi taahhüdü: Eski sistemin kesin kapatma tarihi proje başında ilan edilmeli; yoksa “kalıcı yarım” duruma sürüklenir.
• Veri tutarlılık testi: Paralel çalışma süresince iki sistemin çıktısı her gün karşılaştırılmalı; sapma yüzde 0,5’i geçtiğinde otomatik alarm.
• Trafik aşamalı taşıma: Yüzde 1, 5, 25, 50, 100 dilimleriyle ilerlemek erken sorunları yakalar; her aşama arası 24-72 saat bekleme.
• Geri alma planı: Her aşama için “kaç saniye içinde eski sisteme dönülebilir” sorusu yanıtlanmalı; hedef 30 saniye altı.
• Veri çiftleme maliyeti: CDC ve çift yazma süresince depolama maliyeti yüzde 20-40 artar; bütçeye yansıtılmalı.
• Sürekli özellik üretimi: Geçiş süresince yeni özellik geliştirilmezse iş tarafı projeyi keser; aylık en az 3 yeni özellik teslimi hedefi.
• Takım rotasyonu: Aynı kişiler 18 ay aynı projede burnout yaşar; her 6 ayda yüzde 20 takım rotasyonu sağlıklı.

Ölçüm, Başarı Kriterleri ve KPI Çerçevesi

Geçiş ilerlemesini ölçmek için iş ve teknik metriklerin bir arada izlenmesi gerekir. Sadece “kod satırı taşındı” metriği yanıltıcıdır; gerçek başarı, yeni sistemin iş değerini hızla üretmeye başlamasıdır. DORA dört temel metrik (deployment frequency, lead time, change failure rate, MTTR) her aşamada raporlanmalıdır.

• Trafik dağılımı: Toplam isteklerin yüzde kaçı yeni sistemde işleniyor? Aylık yüzde 5-8 artış hedeflenir.
• Üretim olay sıklığı: Geçiş süresince haftalık olay sayısı baz çizgiye göre nasıl değişti? Hedef baz çizgi ±yüzde 10.
• Dağıtım sıklığı: Yeni servisler haftalık kaç kez üretime çıkıyor? Hedef günlük 1+.
• Değişiklik başarısızlık oranı: Yeni servislerde rollback gerektiren değişiklik oranı yüzde 5’in altında olmalı.
• İş metrikleri: Sepetten alışverişe dönüşüm, sayfa gecikmesi p99, ortalama sipariş süresi.
• Maliyet trendi: Toplam altyapı maliyeti geçici olarak yüzde 30 artar; tamamlandığında baseline’a göre yüzde 15-25 düşmeli.

Kurumsal Strangler Fig Migration Projelerinde Karşılaşılan Tipik Sorunlar

Strangler Fig yıllar içinde olgunlaştı, ancak kurumsal ortamda hala aynı 8 hata tekrarlanıyor. Forrester 2025’in detaylı incelemesinden ve kurumsal teknoloji entegrasyonu deneyimimizden derlediğimiz tipik sorunlar.

• Sınır hatası (yüzde 41 başarısızlığın kaynağı): Bounded context yanlış çizilirse yeni servisler birbirine ağ üzerinden bağımlı kalır; dağıtık monolit doğar.
• Veri sahipliği çatışması: İki servis aynı tabloya yazmaya devam ederse race condition’lar başlar; her hafta 3-7 production olayı yaratır.
• Facade katmanı tek nokta arıza: Tüm trafiğin geçtiği proxy yedeklenmezse, çökmesi tüm sistemi etkiler; minimum üç bölgeli yüksek erişilebilirlik şart.
• CTO sponsorluk kaybı: Sponsorluk yapan yönetici 12 ay içinde değişirse, geçiş yüzde 64 ihtimalle yarıda kalır.
• Test coverage erozyonu: Eski sisteme kimse dokunmadığı için coverage düşer; geçiş süresince eski sistemde de minimum coverage korunmalı.
• Operasyonel yük çatallaşması: Aynı SRE ekibi iki sistemi de izlemekten yorulur; geçici olarak personel artırılmalı.
• Eski sistem kapatma korkusu: “Ya unuttuğumuz bir entegrasyon varsa?” düşüncesi kapatmayı sonsuz erteler; sabit tarih taahhüdü ile aşılır.
• Mikroservis sayısı patlaması: Çok ince granülarite gereksiz operasyonel yük yaratır; başlangıçta 8-15 servis hedefi optimaldir.

Bu sorunlardan korunmak için her geçiş projesi ilk haftada bir “premortem” oturumu düzenlemeli: “Bu proje 18 ay sonra başarısız oldu, sebep neydi?” sorusuyla riskler önceden listelenir ve önlemler proje planına eklenir.

Sık Sorulan Sorular

Sonuç

Strangler Fig Pattern 2026 yılında kurumsal monolit modernizasyonunun en güvenli yoludur. Big bang yaklaşımına göre başarı oranı 3,8 katına çıkarken risk profili dağıtılır, iş sürekliliği korunur ve bütçe öngörülebilirliği yüzde 60-100 sapmadan yüzde 15-25’e iner. Başarı için beş koşul kritik: doğru sınır belirleme (Event Storming + bounded context), kesin bitiş tarihi taahhüdü, sürekli veri tutarlılık testi (parity testing + CDC), aşamalı trafik taşıma (canary release + feature flag) ve sponsorluk istikrarı (CTO seviyesi, minimum 18 ay).

Pattern başlı başına bir mimari karar değil, bir yönetim disiplinidir. Martin Fowler’ın 22 yıl önce tanımladığı bu yaklaşım, AWS Migration Hub’dan ThoughtWorks Tech Radar’a kadar tüm modern modernizasyon çerçevelerinin omurgasını oluşturur. CTO seviyesi sponsorluk, ölçülebilir aşamalı hedefler ve aşağıdan yukarı geri besleme döngüleri ile birleştirildiğinde, 1 milyon satırlık kurumsal monolitler 12-18 ay içinde ölçülebilir riskle ve sürdürülebilir maliyetle modern bir mikroservis mimarisine evrilebilir. Forrester 2025 verilerinin işaret ettiği yön açıktır: 2026’da Strangler Fig artık bir tercih değil, kurumsal teknoloji liderliğinin varsayılan yöntemidir.

Bu Rehberde Kullanılan Kaynaklar

• Forrester Modernization Survey 2025
• Gartner Application Modernization Hype Cycle 2025
• DORA Accelerate State of DevOps 2024
• Martin Fowler — Strangler Fig Application (Orijinal Makale)
• Sam Newman — Monolith to Microservices (O’Reilly, 2. Baskı)
• ThoughtWorks Technology Radar Volume 30-31
• AWS Cloud Migration & Migration Hub Dokümantasyonu
• Domain-Driven Design Reference — Bounded Context
• Debezium CDC Resmi Dokümantasyonu
• Envoy Proxy Production Notes 2025