Mikroservis Mimarisi Geçişi: Monolitik Sistem Bölme Stratejisi

Monolitik uygulama 5 kişilik bir ekiple 18 ay boyunca sorunsuz akar; 30 kişiyi geçtiğinde her sprintte “ben buraya dokunursam patlatırım” cümlesi 7-10 kez tekrarlanır, deployment frekansı haftada 3’ten 0.8’e düşer, lead time 4 saatten 28 saate çıkar. Bu noktada CTO masasına “mikroservise geçelim” önerisi gelir. Ancak ThoughtWorks Tech Radar 2025 verisine göre 2023-2025 arası başlatılan kurumsal mikroservis geçişlerinin yalnızca %42’si 24 ay içinde net pozitif ROI üretmiş; %58’i teknik borcu farklı bir yere taşıyarak distributed monolith adıyla bilinen anti-pattern’e dönüşmüştür. Datadog State of DevOps 2025 raporu 1.847 kurumsal müşterinin telemetrisini incelediğinde, doğru bölünmüş mikroservis ekiplerinin DORA 4 metriklerinde %3.2 kat (deployment frequency), %4.1 kat (lead time) iyileşme yakaladığını gösteriyor — fakat aynı raporda yanlış bölünmüş sistemlerin MTTR’sinin 2.7 kat arttığı altı çiziliyor. Bu yazı, monolitik bir sistemden mikroservise geçişi 2026 koşullarında “modular monolith first, microservices second” prensibi etrafında, Strangler Fig Pattern, Domain-Driven Design (DDD), Saga, CQRS, event-driven mimari, service mesh ve distributed tracing katmanlarıyla uçtan uca ele alıyor; her bölüm gerçek kurumsal projelerde karşılaşılan rakamsal eşikler ve karar matrisleri ile destekleniyor.

Mikroservise Geçiş Kararının 7 Sayısal Eşiği ve Modular Monolith İlk Adımı

Sam Newman’ın “Building Microservices” 2. baskısında (2021) açıkça vurguladığı tez şudur: mikroservis bir hedef değil bir araçtır, ve aracın maliyeti faydadan büyükse seçilmemelidir. 2026’da bu tez yerini “modular monolith first” yaklaşımına bırakmış durumda — Shopify, GitHub, Stack Overflow gibi yüksek ölçekli platformlar 2023-2025 arasında “ters yön” hareketler yaparak bazı mikroservislerini yeniden modüler monolit içine birleştirdi. Geçiş kararı için 7 sayısal eşik:

• Ekip ölçeği: 5+ feature ekibi, takım başına 4-8 mühendis, toplam 30+ aktif geliştirici.
• Codebase büyüklüğü: 200.000+ satır kod, 800+ aktif modül, ortalama build süresi 12 dakikayı aşıyor.
• Deployment frekansı çakışması: Haftada 15+ deployment, takımlar arası “merge çakışma” oranı %18’in üzerinde.
• Ölçek asimetrisi: Modüllerin %20’si CPU/RAM kullanımının %70’ini tüketiyor (bağımsız ölçek ihtiyacı).
• Teknoloji çeşitlilik baskısı: ML/data servisleri Python, ana stack JVM; tek runtime’da iki ekosistemi taşımak verimsiz.
• Lead time degradasyonu: Feature başına lead time 6 ay öncesine göre %200+ artmış durumda.
• Test süresi: Full regression test paketi 90 dakikayı geçiyor ve paralelleştirme bile çare olmuyor.

Bu 7 eşikten en az 4’ü işaretliyorsa geçiş gerekçelidir; aksi halde modular monolith (örn. Spring Modulith, .NET Modular Monolith, Rails Packwerk) yeterli kalır. Modular monolith hakkında detaylı kurulum şablonu için modular monolith ara istasyon rehberini incelemekte fayda var.

Strangler Fig Pattern: Big-Bang Yerine Aşamalı Mikroservis Çıkarma

Adını Martin Fowler’ın 2004 yılında yayınladığı StranglerFigApplication makalesinden alan Strangler Fig Pattern, Avustralya’daki gerçek strangler fig ağacının ev sahibi ağacı yavaş yavaş sarıp emekliye ayırmasından esinlenir. Big-Bang rewrite yaklaşımının başarısızlık oranı, ThoughtWorks 2024 raporuna göre %71; aynı raporda Strangler Fig ile yürütülen geçişlerin başarı oranı %83 olarak ölçülmüştür. Strangler Fig 6 adımlı operasyonel akış:

1. Monolitik önüne ters proxy veya API gateway yerleştir (Nginx, Kong, Envoy, AWS API Gateway).
2. Domain-Driven Design ile bounded context haritası çıkar, ilk çıkarılacak servisi seç.
3. Anti-Corruption Layer kur — yeni servis ile eski monolith’i veri model “bulaşması” olmadan konuş.
4. Trafiği canary deployment ile %1, %5, %20, %50, %100 oranında yeni servise kaydır.
5. Eski koddaki ilgili modülü “dead code” işaretle, 4-8 hafta gözlem sonrası sil.
6. Bir sonraki bounded context için 2-6 adımları tekrarla.

Strangler Fig pattern’inin detaylı kod-seviye uygulaması için aşamalı mikroservis geçişi yazısı referans alınabilir; Anti-Corruption Layer kurulumunu derinlemesine ele aldığımız ayrı bir rehber için ACL mimarisi yazısı tamamlayıcıdır.

Domain-Driven Design ve Bounded Context: Servis Sınırı Çizmenin Bilimsel Yöntemi

Eric Evans’ın 2003’te yayınladığı Domain-Driven Design kitabı 23 yıl sonra hâlâ mikroservis literatürünün ana iskeleti. Mikroservis geçişlerinin %58 başarısızlık oranının kök nedeni AWS Microservices belgelerinde “incorrect service boundaries” olarak tanımlanır — yani sınırı yanlış çizmek. Bounded Context belirleme 5 aşamalı pratik akış:

• Event Storming workshop: 8-15 kişilik domain expert + mühendis grubu, 2 gün boyunca post-it ile domain event’lerini haritalandırır.
• Ubiquitous Language tanımı: Her bounded context’in kendi sözlüğü çıkarılır; “customer” sipariş context’inde başka, support context’inde başka tanımlanabilir.
• Aggregate kökleri: Tutarlılık sınırı taşıyan en küçük varlık grubu (örn. Order + OrderItem) belirlenir.
• Context Map: Bounded context’ler arası ilişkiler (Partnership, Customer-Supplier, Conformist, ACL, Open Host Service, Published Language) görsel haritada işaretlenir.
• Servis adaylığı doğrulaması: Her bounded context için “ekip, veri, deployment, ölçek” 4 boyutu test edilir; 4 boyutta da bağımsızlık varsa servis adayıdır.

Bounded Context Tipi	Ekip Sayısı	Veri Sahipliği	Servis Adaylığı
Core Domain	2-4 ekip	Tam	Yüksek öncelik
Supporting Domain	1-2 ekip	Tam	Orta öncelik
Generic Domain	0-1 ekip	Kısmi	SaaS al, yazma
Legacy Cohesive Module	1 ekip	Bulanık	Önce modüler monolit
Shared Kernel	2+ ekip	Ortak	Servisleştirme uygun değil

DDD’yi pratik kurumsal projelerde uygulamak için DDD kurumsal mimari rehberi ile başlanabilir; test edilebilir mimari kurmak için hexagonal architecture yazısı tamamlayıcıdır.

Senkron ve Asenkron İletişim: Cascading Failure’dan Eventual Consistency’ye

Servisler arası iletişim modelinin seçimi sistemin doğal davranışını belirler. Senkron çağrı zincirinde 5 servis ardışık çağrıldığında, her servisin %99.9 uptime’ı varsa bütün zincir uptime’ı %99.5’e düşer — yani yılda 43.8 saatten 43.8 saate çıkar. Bu hesap kurumsal SLA müzakerelerinde sık atlanır.

İletişim Modeli	Protokol/Tool	Tipik Latency	Tutarlılık	Tipik Kullanım
Senkron REST	HTTP/JSON	20-100 ms	Strong	User-facing okuma
Senkron gRPC	HTTP/2 + Protobuf	5-30 ms	Strong	Servisler arası kritik yol
Asenkron Event	Kafka, Pulsar	50-500 ms	Eventual	Domain event yayını
Asenkron Queue	RabbitMQ, SQS	30-300 ms	Eventual	Task offloading
Hybrid CQRS	Read API + Event	10-200 ms	Eventual	Read-heavy domain

Distributed transaction’ları yönetmek için Saga Pattern 2026’da fiili standart: Orchestration tabanlı Saga (Camunda, Temporal, AWS Step Functions) ile Choreography tabanlı Saga (Kafka event chain) arasında seçim, sistemin denetlenebilirlik ihtiyacına göre yapılır. CQRS uygulamak isteyen ekipler için detaylı yaklaşım CQRS ve Event Sourcing rehberinde; Apache Kafka tabanlı event-driven mimari kurulumu event-driven mimari yazısında detaylandırılmıştır.

Service Mesh, API Gateway ve Distributed Tracing: Operasyonel Katmanın Anatomisi

Servis sayısı 10’u geçtiğinde, kod tabanına yazılmış cross-cutting concern’ler (retry, timeout, circuit breaker, mTLS, observability) bakımı pahalı hale gelir. Service mesh bu sorumlulukları “sidecar proxy” katmanına taşır.

Service Mesh	Sidecar	Kontrol Düzlemi RAM	P99 Latency Eki	Tipik Ölçek
Istio 1.24	Envoy	800 MB-2 GB	3-7 ms	100+ servis
Linkerd 2.16	linkerd2-proxy	150-400 MB	1-3 ms	20-200 servis
Consul Connect 1.20	Envoy/Built-in	500 MB-1.2 GB	2-5 ms	50-300 servis
Cilium Service Mesh	eBPF (sidecarsız)	200-600 MB	0.5-2 ms	500+ servis
AWS App Mesh	Envoy	Managed	2-6 ms	AWS-only 100+ servis

Service mesh çözümlerinin maliyet/fayda analizi ve seçim kriterleri service mesh karşılaştırma yazısında ele alınıyor. API Gateway katmanı (Kong 3.x, AWS API Gateway, Apigee, Tyk) authentication, rate limiting, request transformation ve OpenAPI doğrulama görevlerini üstlenir; mikroservis sayısı 15’i geçtiğinde gateway zorunlu hale gelir. Distributed tracing 2026’da OpenTelemetry standardı etrafında konsolide oldu. Jaeger, Tempo, Honeycomb, Datadog APM, New Relic, Dynatrace farklı backend seçenekleri sunuyor; tracing instrumentation’ın baştan kurulmaması, geçişin %63’lük bir alt-başarısızlık alanını oluşturuyor (Datadog 2025).

Data Consistency, CQRS ve Outbox: Dağıtık Veri Tutarlılığının 4 Pratik Aracı

Monolitik dünyada ACID transaction tek bir veritabanı motorunda halledilir. Mikroservis dünyasında her servisin kendi veri deposu vardır ve 2-phase commit (2PC) %95+ vakada uygun değildir — performans ve operasyonel maliyet getirisi düşüktür. 2026 standart araç seti şudur:

• Saga Pattern: Uzun süreli iş süreçlerini kompensasyon transaction’larıyla yönetir. Orchestration için Temporal 1.24 ve Camunda 8 öne çıkar.
• Outbox Pattern: Domain DB yazımı + event yayını atomik hale gelir. Debezium 2.x ile Postgres logical replication üzerinden 50.000+ event/sec throughput erişilebilir.
• CQRS: Read ve write modelleri ayrıştırılır; read tarafı denormalize, indexlenmiş, ölçeklenir.
• Event Sourcing: Durum yerine event log saklanır; audit, debugging ve “time travel” yetenekleri açılır. EventStoreDB, Axon, Marten tipik araçlar.

Tutarlılık Aracı	Tipik Throughput	Operasyonel Yük	Audit Yeteneği	Eşik
Saga Orchestration	1.000-10.000 saga/saniye	Orta	Yüksek	5+ servis arası iş akışı
Saga Choreography	10.000+ event/saniye	Düşük başlangıç, yüksek bakım	Orta	3-7 servis
Outbox Pattern	50.000+ event/saniye	Düşük	Yüksek	Domain event yayını
CQRS	Read 100K+ rps	Yüksek	Modele bağlı	Read-heavy domain
Event Sourcing	20.000+ event/saniye	Yüksek	Tam audit	Finansal/regulatory domain

Deployment Patternleri: Canary, Blue-Green, Feature Flag ile Sıfır Downtime

Mikroservis dünyasında deployment artık “servisi durdur, yeni versiyonu başlat” değildir. Kubernetes Deployment, ArgoCD, Argo Rollouts, Flagger 2026’da olgun deployment pipeline’ları sunuyor. 4 ana deployment paterni:

1. Rolling Update: Pod’lar batch’ler halinde değişir, varsayılan Kubernetes davranışıdır. %1 trafik kaybı tipik.
2. Blue-Green Deployment: İki paralel ortam, trafik bir DNS/load balancer kararıyla anlık aktarılır. Rollback 30 saniyenin altında.
3. Canary Deployment: Yeni versiyon önce %1-5 trafiği alır, metriklere göre kademeli artırılır. Argo Rollouts + Prometheus + Flagger üçlüsü standarttır.
4. Feature Flag: Deployment ile release ayrılır. LaunchDarkly, Unleash, GrowthBook 2026’da yaygın araçlar.

DORA 2024 raporuna göre yüksek performanslı ekipler haftada 7+ deployment yapar; düşük performanslı ekipler ayda 1 deployment seviyesinde kalır. Mikroservis mimarisi bu farkı 30 kat büyütebilir, fakat yalnızca CI/CD pipeline disiplini olduğunda.

Kurumsal Mikroservis Geçiş Projelerinde Karşılaşılan Tipik Sorunlar

Birden fazla kurumsal mikroservis projesini yakından izleyen bir teknoloji ortağı olarak, geçiş esnasında en sık karşılaştığım sorunları sıralıyorum. Bu liste, AWS Microservices best practice belgeleri, Datadog State of DevOps 2025 verisi ve sahadan gözlemlerin sentezidir.

• Distributed Monolith tuzağı: Servisler ayrı, ama her isteği 5-8 servis senkron çağırıyor. Tek servis düştüğünde tüm sistem düşer. Tespit: cascading failure simülasyonu (Chaos Engineering).
• Shared Database anti-pattern: 3 servis aynı tabloya yazıyor. Bağımlılık gizli, schema değişimi 3 ekibi etkiliyor. Çözüm: database per service + Outbox.
• Observability geç eklenmesi: 12 servis kurulduktan sonra distributed tracing entegrasyonu çalışması 6-9 ay sürüyor. Çözüm: OpenTelemetry SDK ilk servisle birlikte gelir.
• Aşırı granüler servisler: “AuthService”, “TokenService”, “PermissionService” gibi 200-400 satırlık mikro-mikroservisler. Operasyonel yük (deployment, monitoring, on-call) faydadan büyük.
• API versiyonlama yokluğu: Servis A’nın API kırılması Servis B’yi düşürüyor. Çözüm: Semantic versioning + Consumer-Driven Contract testing (Pact 4.x).
• Yetersiz on-call disiplini: “You build it, you run it” prensibi söylenir ama pratikte tek SRE ekibi 40+ servisi taşıyor. Sürdürülemez.
• Cross-cutting değişikliklerin gecikmesi: Yeni bir security header’ı 18 servise eklemek 4-6 ay sürüyor. Çözüm: service mesh + paylaşılan SDK politikası.
• Ekip ayarlaması yapılmadan teknik bölme: Conway Yasası ihmal edilir; 1 ekip 9 servise sahip olmaya başlar, sahiplenme erozyona uğrar.
• Yetersiz cost observability: Servis başına FinOps metriği olmadan, bulut faturası %200 büyür ve sorumlu bulunamaz.

Sorun	Tipik Süresi	Maliyet Etkisi	Önerilen Çözüm
Distributed Monolith	9-18 ay	2-3x altyapı maliyeti	Async event-driven yeniden bölme
Shared Database	6-12 ay	Schema lock geciktirir	Database per service + ACL
Observability gap	6-9 ay	MTTR 3x artar	OpenTelemetry day-1
Aşırı granülerlik	12-24 ay	On-call yorgunluğu	Servis birleştirme
Cost gözlemsizliği	3-6 ay	%150-300 fatura artışı	FinOps platformu + tag policy

Sıkça Sorulan Sorular

Monolitten mikroservise geçiş ortalama ne kadar sürer?

ThoughtWorks 2024 verisine göre 200.000-1.000.000 satır arası bir codebase için tipik süreç 18-36 aydır. Strangler Fig pattern uygulanırsa 6. ayda ilk 3-4 servis canlıya alınır, 18. ayda monolit %50 küçülmüş olur, 30-36. ayda kalıcı bir hibrit yapı oturur. Tek seferde tamamlanan “Big-Bang” yaklaşımı 2026’da artık tavsiye edilmiyor; başarısızlık oranı %71.

Modular monolith mı, mikroservis mi seçmeliyim?

2026 konsensüsü “modular monolith first, microservices second” yönünde. Ekip 25 kişinin altındaysa, codebase 200.000 satırın altındaysa, deployment frekansı sorun değilse modular monolith neredeyse her zaman daha iyidir. Mikroservise geçiş kararı için bu yazıda listelenen 7 sayısal eşikten en az 4’ünün karşılanması gerekir.

Servisler arası senkron mı asenkron mu iletişim seçmeliyim?

Hibrit. User-facing okuma akışlarında (latency hassas, strong consistency gereken) gRPC veya REST senkron. Sistem-içi domain event yayınında Kafka veya RabbitMQ asenkron. Kritik kuralı: bir kullanıcı isteğinin tetiklediği senkron çağrı zinciri 3 servisi geçmemeli. 3’ü geçtiyse ya hibrit önbellek (CQRS read model) ya da choreography saga ile asenkrona çevrilmeli.

Service mesh ne zaman gerekli, kurulum maliyeti nedir?

Servis sayısı 10-15’i geçtiğinde mTLS, retry, circuit breaker politikalarını kütüphane olarak yönetmek bakım maliyetli hale gelir. Linkerd kurulumu 2-4 hafta, Istio kurulumu 6-12 hafta tipik. Cluster başına RAM ek yükü 200 MB-2 GB; P99 latency eki 1-7 ms aralığında. 50+ servisli ortamda fayda nettir; 10’un altında genellikle erken yatırım olur.

Distributed transaction’ları nasıl yönetmeliyim?

2-phase commit %95+ vakada yanlış seçim. Saga Pattern fiili standart. İki varyant: Orchestration (Temporal, Camunda) merkezi koordinatör, denetlenebilirlik yüksek, vendor lock-in riski var. Choreography (Kafka event chain) decoupled, fakat süreç görünürlüğü düşük. 5+ servis üzerinde uzun süreli iş akışlarında orchestration; 3-5 servis arası basit akışlarda choreography tercih edilir.

Mikroservis geçişinde en kritik teknik karar hangisidir?

Sınır çizimi (bounded context belirleme). AWS Microservices belgelerinde geçiş başarısızlığının kök nedenlerinin %58’i yanlış servis sınırına dayandırılır. Event Storming workshop ve Domain-Driven Design Context Map çalışması ilk 4-8 haftada yapılmalı; bir bounded context’in “ekip, veri, deployment, ölçek” 4 boyutunda bağımsız olduğu test edilmeli.

Sonuç

Mikroservis bir teknoloji modası değil; doğru koşullarda doğru fayda sağlayan bir mimari kararıdır. 2026’da olgun ekipler “modular monolith first” ile başlıyor, sayısal eşikler aşıldığında Strangler Fig Pattern ile aşamalı geçişe çıkıyor, Domain-Driven Design Bounded Context çalışması ile sınırı doğru çiziyor, Saga ve Outbox ile veri tutarlılığını yönetiyor, service mesh ve OpenTelemetry ile operasyonel katmanı sağlamlaştırıyor. Tüm bu kararlar tek bir kurumsal stratejik çerçevenin parçasıdır — yazılım mimarisi seçimleri AI entegrasyonu, veri stratejisi ve risk yönetimi ile birlikte planlandığında sürdürülebilir değer üretir. Kurumsal teknoloji yatırım kararlarınızı bütünsel bir çerçevede ele almak için 2026 kurumsal yapay zeka entegrasyonu pillar rehberini okuyabilirsiniz. Detaylı kaynaklar için Martin Fowler’ın microservices kütüphanesi, Sam Newman’ın kişisel arşivi, AWS Microservices belgeleri, ThoughtWorks Technology Radar, Datadog State of DevOps ve DORA Research birinci-elden referanslardır.