Monolitten Mikroservislere Geçiş: 2026 Mimari Refaktör Rehberi

Kritik bir monolit uygulamayı dağıtık mikroservislere taşımak, bir mühendislik organizasyonunun üstlenebileceği en yüksek riskli dönüşümlerden biridir. Doğru yapıldığında bağımsız dağıtım hızı, yatay ölçeklenebilirlik ve izole hata alanları kazandırır. Yanlış yapıldığında ise ortaya dağıtık monolit (distributed monolith) çıkar: mikroservislerin bütün operasyonel maliyeti, hiçbir avantajı olmadan.

Bu rehber, yük altında çalışan üretim sistemlerini modernize eden saha deneyiminden yazılmıştır. Karar çerçevesini, geçiş mekaniğini, projelerin çoğunu batıran veritabanı problemini ve olmadığında mimarinin ayakta duramayacağı organizasyonel değişiklikleri kapsar.

Öne çıkanlar

Mimari modaya göre değil, adını koyabildiğiniz somut bir kısıt için geçin. Kısıtın adını koyamıyorsanız, doğru ve daha ucuz cevap modüler monolittir.
Strangler Fig deseni — bir yönlendirme katmanının arkasında kademeli çıkarma — kurumsal ölçekte tek sorumlu stratejidir. Tek seferde tam yeniden yazımın başarısızlık oranı tartışmayı bitirecek düzeydedir.
Zor kısım kod çıkarma değil, veritabanı ayrıştırmadır. Eforun %60–70'ini buraya ayırın.
Gözlemlenebilirlik, CI/CD ve test güvenlik ağı önceden yoksa güvenli geçiş mümkün değildir. Bunlar çıktı değil, ön koşuldur.
Conway Yasası bir tavsiye değil, bir kısıttır. Planlasanız da planlamasanız da mimariniz organizasyon şemanıza yakınsayacaktır.

1. Gerçekten geçmeli misiniz? Dürüst bir karar çerçevesi

Bir mimarın sunabileceği en değerli hizmet bazen müşteriyi geçişten vazgeçirmektir. Mikroservisler geliştirme karmaşıklığını operasyonel karmaşıklıkla takas eder ve bu takas yalnızca belirli koşullarda kârlıdır.

Somut bir kısıt gösterebiliyorsanız geçin

Kısıt	Ölçebileceğiniz belirti	Mikroservis çözer mi?
Dağıtım bağımlılığı	Bir ekibin sürümü dört ekibi bloke ediyor; sürüm treni haftalık veya daha yavaş	Evet — en güçlü gerekçe
Farklı ölçekleme profilleri	Ödeme akışı CPU'nun %80'ini yerken sistemin geri kalanı boşta; tek uç nokta için tüm monoliti ölçekliyorsunuz	Evet
Patlama yarıçapı	Raporlama modülündeki bellek sızıntısı ödemeleri düşürüyor	Evet
Teknoloji kilitlenmesi	Yapay zekâ iş yükleri Python istiyor, monolit Java 8	Evet
Ekip ölçeği	40+ mühendis tek kod tabanı ve tek sürüm hattı üzerinde çekişiyor	Evet
"Kodumuz dağınık"	Yüksek çevrimsel karmaşıklık, düşük test kapsamı	Hayır — dağıtım dağınıklığı büyütür
"Sistem yavaş"	p95 gecikmesinin kaynağı indekssiz sorgular veya N+1 erişim deseni	Hayır — topolojiyi değil sorgu planını düzeltin
"Modern şirketler böyle yapıyor"	—	Hayır

Çoğu ekibin önce seçmesi gereken yol: modüler monolit

Ağ üzerinden dağıtmadan önce sınırları süreç içinde zorunlu kılın. Kod tabanını açıkça yayımlanmış arayüzlere sahip modüllere bölün, modüller arası veritabanı erişimini yasaklayın ve bunu CI'da bir mimari uygunluk testiyle denetleyin (JVM için ArchUnit, Python için import-linter, Node için dependency-cruiser, PHP için deptrac).

Bu yaklaşım modülerlik faydasının yaklaşık %70'ini, operasyonel maliyetin yaklaşık %10'una verir. Daha önemlisi, gerçek bir geçişin de doğru ilk adımıdır: sınırları temiz modüller neredeyse mekanik biçimde servise dönüşür; sınırı olmayanlar ise hiç dönüşmez.

Mimar kuralı: Tek bir süreç içinde temiz bir modül sınırı çizemiyorsanız, ağ üzerinden hiç çizemezsiniz. Ağ, henüz çözmediğiniz probleme yalnızca gecikme ve kısmi hata ekler.

2. Geçiş öncesi hazırlık: dört ön koşul

Gözlemleyemediğiniz ve geri alamadığınız bir sisteme çıkarma yapmak modernizasyon değil, risk transferidir. Bu dördü sağlanmadan ilk servisi kesmeyin.

2.1 Gözlemlenebilirlik temeli

Monoliti dokunmadan önce enstrümante edin; enstrümantasyonun geçişten sağ çıkması için OpenTelemetry kullanın:

Her gelen istekte yayılan bir korelasyon kimliğiyle dağıtık izleme (distributed tracing). Bu olmadan dağıtık sistemdeki ilk üretim olayınız dakikalar değil günler alır.
Uç nokta bazında RED metrikleri — Rate, Errors, Duration (p50/p95/p99). Bunlar regresyon sözleşmeniz olur: çıkarılan servis monolitin rakamlarını yakalamalı veya geçmelidir.
İz kimlikleri taşıyan, merkezî depoya gönderilen yapılandırılmış JSON loglama.
İş düzeyinde SLO'lar, örneğin: "ödeme isteklerinin %99,9'u 800 ms altında tamamlanır." Teknik metrikler sistemi ölçer; SLO müşteriye verilen sözü ölçer.

2.2 Dağıtım otomasyonu

Çıkardığınız her servis dağıtım yüzeyinizi katlar. Bugün dağıtım manuelse, çıkarma işlemi tek acılı dağıtımı on beşe çevirir. Başlamadan önce gerekli olanlar: tek komutla dağıtım, otomatik geri alma, değişmez derleme artefaktları ve Kod olarak Altyapı (Terraform, Pulumi veya OpenTofu) ile ortam eşitliği.

2.3 Karakterizasyon testi altyapısı

Eski sistemlerde yeterli birim testi nadiren bulunur ve sonradan eklemek çoğu zaman ekonomik değildir. Bunun yerine karakterizasyon testleri kurun: kesmeyi planladığınız sınırda gerçek üretim istek/yanıt çiftlerini yakalayın ve yeni servisin bunları birebir ürettiğini doğrulayın. Bir spesifikasyona karşı doğruluğu değil, mevcut davranışa denkliği — hatalar dahil — test ediyorsunuz. Çünkü aşağı akıştaki tüketiciler o hatalara bağımlı hâle gelmiştir.

2.4 DORA temel ölçümü

Dağıtım sıklığı, değişiklik teslim süresi, değişiklik hata oranı ve ortalama onarım süresini geçişten önce kaydedin. Temel ölçüm olmadan yönetime değer kanıtlayamazsınız; proje izlenimlere göre yargılanır ve bu da en yüksek sesle şikâyet edenin lehine işler.

3. Alan keşfi: kesim çizgilerini bulmak

Haritasını çıkarmadığınız bir alandan servis çıkaramazsınız. Bu işi kod yazmadan önce yapın.

3.1 Event storming

Alan uzmanlarını ve mühendisleri tek odada (veya tek Miro panosunda) toplayıp iş olaylarını zaman sırasına dizin: SiparişVerildi → ÖdemeYetkilendirildi → StokRezerveEdildi → SevkiyatÇıktı. Ortak sözlük ve sahiplik paylaşan olay kümeleri sınırlı bağlamları (bounded contexts) — yani aday servis sınırlarınızı — açığa çıkarır.

Aranacak sinyal dil ayrışmasıdır. Satış "müşteri" deyip potansiyel adayı kastederken Faturalama "müşteri" deyip ödeme yöntemi olan bir varlığı kastediyorsa, bir sınır bulmuşsunuz demektir. İki sınırlı bağlam, iki model ve aralarında tek bir çeviri katmanı.

3.2 Depoyu ampirik kesim çizgileri için tarayın

Alan teorisi kanıtla doğrulanmalıdır:

# Birlikte değişen dosyalar bağımlıdır — mimari şema ne derse desin
git log --format=format: --name-only --since=18.months.ago \
  | sort | uniq -c | sort -rg | head -60

CodeScene gibi araçlar veya basit bir birlikte-değişim matrisi zamansal bağlaşımı ortaya koyar: sürekli aynı commit içinde değişen dosyalar, bugün hangi pakette yaşarlarsa yaşasınlar aynı servise aittir. Yoğun bir birlikte-değişim kümesinin ortasından geçen bir sınır önerisi, sürekli servisler arası pull request üretecektir ve yeniden çizilmelidir.

3.3 Riske göre düzeltilmiş değere göre sıralayın

Her adayı puanlayın: iş değeri × değişim sıklığı ÷ (bağlaşım × veri iç içeliği). Azalan sırayla çıkarın. Çıkardığınız ilk servis çevresel, iyi anlaşılmış ve düşük riskli olmalıdır — bildirimler, PDF üretimi, arama indeksleme. Burada pipeline'ı, dağıtım yolunu, gözlemlenebilirlik bağlantılarını ve ekibin kas hafızasını test ediyorsunuz. Bu dersleri ödeme akışında öğrenmeyin.

4. Strangler Fig deseni uygulamada

Adını, konak ağacı sarıp zamanla onun yerini alan sarmaşıktan alan bu desen, iki sistem paralel çalışırken trafiği kademeli olarak monolitten yeni servislere yönlendirir.

4.1 Önce yönlendirme katmanını yerleştirin

Monolitin önüne bir API Gateway veya ters proxy (Kong, Envoy, NGINX, AWS API Gateway, Traefik) koyun — trafiğin %100'ü hâlâ monolite giderken. Bu, tasarım gereği hiçbir davranış değiştirmeyen bir dağıtımdır: amaç, yönlendirme katmanının herhangi bir geçiş riski taşımadan önce kararlı ve gözlemlenebilir olduğunu kanıtlamaktır.

4.2 Yedi adımlı çıkarma döngüsü

Her servis için tekrarlayın:

Önce sözleşmeyi tanımlayın. OpenAPI veya Protobuf; tüketiciler tarafından gözden geçirilmiş, şema kayıt defterinde sürümlenmiş. Teslim edilen şey sözleşmedir; implementasyon ayrıntıdır.
Servisi mevcut veritabanı üzerine kurun. Veriyi henüz ayrıştırmayın. Aynı anda tek değişken.
Gölge trafik (shadow traffic). Üretim isteklerini yeni servise aynalayın, yanıtlarını atın ve monolitin yanıtlarıyla farkını alın. Bu, tam üretim hacminde ve sıfır müşteri riskiyle davranışsal sapmayı ortaya çıkarır. En az bir tam iş döngüsü çalıştırın — çoğu sistem için bir hafta, aylık toplu işleriniz varsa bir ay.
Kademeli yayın (canary). %1 → %5 → %25 → %50 → %100, SLO hata bütçesi tüketim hızına bağlı olarak. Geri alma tetiğini otomatikleştirin; saat 03:00'te panoya bakan bir insan kontrol mekanizması değildir.
Monolit yolunu devre dışı bırakın. Eski kodu silin, yorum satırına almayın. "Belki lazım olur" denilen ölü kod, bir geçişin kalıcı ikinci sisteme dönüşme yoludur.
Veriyi ayrıştırın. Bkz. bölüm 5.
Canlıya almadan önce sahiplik, SLO'lar, runbook ve nöbet rotasyonunu içeren bir servis README'si yayımlayın.

4.3 Yozlaşma önleyici katmanlar

Yeni servisler monolitin eski modelini miras almamalıdır. Sınıra, eski yapıları yeni alan modeline çeviren bir yozlaşma önleyici katman (anti-corruption layer) koyun. Aksi hâlde 140 boş bırakılabilir sütunlu ve üç aşırı yüklenmiş durum bayrağına sahip customers tablonuz kurduğunuz her servise yayılır; karmaşayı çözmüş değil, dağıtmış olursunuz.

5. Veritabanı ayrıştırma: geçişlerin asıl battığı yer

Kod çıkarma çözülmüş bir problemdir. Projeleri on sekiz ay boyunca durduran şey veri ayrıştırmadır. Planınızı buna göre yapın.

5.1 Paylaşılan veritabanı anti-deseni

Birden fazla servisin aynı tabloları okuyup yazması şu demektir: bağımsız dağıtım yok (şema değişikliği alakasız servisleri kırar), bağımsız ölçekleme yok, net sahiplik yok ve değişmezler üzerinde akıl yürütme imkânı yok. Paylaşılan veritabanı üzerindeki bir "mikroservis" sistemi dağıtık monolittir — başladığınız monolitten kesinlikle daha kötüdür, çünkü özerklik kazanmadan ağ gecikmesi ve kısmi hata eklemişsinizdir.

5.2 Aşama A — Fiziksel ayrımdan önce mantıksal ayrım

Mevcut veritabanının içinde başlayın. Tablo sahipliğini sınırlı bağlam başına atayın, bağlamlar arası yazma yetkilerini veritabanı kullanıcı düzeyinde geri alın (bu, sınırı belgelenmiş değil zorunlu kılar) ve bağlamlar arası JOIN'leri API çağrıları veya okuma modelleriyle değiştirin.

Hangi join'lerin gerçekten yük taşıdığını bu aşamada keşfedersiniz. Rahatsız edici olmasını bekleyin; ancak burada keşfetmek fiziksel ayrımdan sonra keşfetmekten çok daha ucuzdur.

5.3 Aşama B — Join'leri kırmak

Tercih sırasına göre üç araç:

API kompozisyonu. Servis, sahip servisi çağırır. Basit ve tutarlıdır, bir ağ sekmesi ekler. Düşük hacimli yollar için doğru varsayılan.
Okuma modelleri / CQRS projeksiyonları. Tüketen servis, olaylarla güncellenen kendi denormalize kopyasını tutar. Hızlı okuma, nihai tutarlılık, ek karmaşıklık. Yüksek hacimli okuma yolları için doğru seçim.
Tasarım gereği veri çoğaltma. Gerçekten ihtiyaç duyduğunuz alanları kopyalayın. Bir sipariş, müşterinin adını ve adresini sipariş anındaki hâliyle saklar — bu bir önbellek değil, tarihsel olarak doğru bir iş gerçeğidir. Hangi çoğaltmanın anlamsal olarak doğru, hangisinin yalnızca pratik olduğunu ayırt etmek temel bir modelleme becerisidir.

5.4 Aşama C — İşlemsel outbox

Tüm geçişin en önemli tek deseni budur. Bir servis hem veritabanını güncelleyip hem de bir olay yayımlamak zorunda kaldığında, naif uygulama önce satırı yazar sonra yayımlar. Süreç arada çökerse durum ile olay kalıcı olarak ayrışır ve bunu düzelten hiçbir çift yazma protokolü yoktur.

Outbox deseni her iki yazmayı atomik hâle getirir:

BEGIN;
  UPDATE orders SET status = 'CONFIRMED' WHERE id = $1;
  INSERT INTO outbox (aggregate_id, event_type, payload, created_at)
  VALUES ($1, 'OrderConfirmed', $2, now());
COMMIT;

Ayrı bir aktarım süreci — write-ahead log'u okuyan Debezium veya basit bir yoklayıcı — outbox satırlarını Kafka/Kinesis/Pub-Sub'a yayımlar ve gönderildi olarak işaretler. Teslimat en az bir kez (at-least-once) olduğundan her tüketici idempotent olmalıdır: kararlı bir olay kimliğiyle tekilleştirin veya işleyiciyi doğal olarak idempotent yapın (increment yerine SET status = 'X').

5.5 Aşama D — Tarihsel veriyi taşıyıp cutover yapmak

Tarihsel satırları yeni depoya geri doldurun (backfill); partiler hâlinde ve üretim I/O'sunu korumak için kısıtlanmış hızda.
Yeni servis üzerinden çift yazma yapın; okumalarda eski yol hâlâ otorite olsun.
Sürekli mutabakat — her iki depodaki satır sayılarını ve sağlama toplamlarını karşılaştıran, sapmada alarm üreten zamanlanmış bir iş. Bunu atlamayın; altı hafta sonra fark edilen sessiz sapma bir yazılım hatası değil, veri bütünlüğü olayıdır.
Anlık geri alma yolu bırakarak, uç nokta uç nokta bir feature flag arkasında okumaları devredin.
Çift yazmayı durdurun, ardından eski tabloları silin — tanımlı bir saklama penceresi ve doğrulanmış bir yedekten sonra.

5.6 Dağıtık işlemler: 2PC değil, saga

Servisler arası iki fazlı commit bir erişilebilirlik tuzağıdır: her katılımcının canlılığını birbirine bağlar. Bunun yerine saga kullanın — her biri telafi eylemine sahip yerel işlemler dizisi.

Stok rezerve et  →  Ödemeyi tahsil et  →  Sevkiyat oluştur
     ↓ telafi            ↓ telafi              ↓ telafi
Stoğu serbest    ←   İade et          ←   Sevkiyatı iptal et

Bunun açığa çıkardığı iş gerçeğine dikkat edin: telafi bir geri alma değildir. İade, müşterinin ekstresinde görünen yeni bir iş olayıdır. Dolayısıyla saga tasarımı teknik olduğu kadar bir ürün konuşmasıdır ve ürün sahipleri o odada bulunmalıdır.

6. Dağıtık sistem vergisi

Her mikroservis mimarisi bu maliyetleri öder. Bütçesini açıkça ayırın.

Maliyet	Hata biçimi	Önlem
Ağ gecikmesi	20 ms'lik 5 ardışık çağrı = p50'ye 100 ms ek	Bağımsız çağrıları paralelleştirin; gevezelik eden sınırları birleştirin; okuma modeli ekleyin
Kısmi hata	Yavaş bir bağımlılık çağıranın iş parçacığı havuzunu tüketip zincirleme çökertir	Her çağrıda zaman aşımı, devre kesiciler, bulkhead, jitter'lı üstel geri çekilme
Nihai tutarlılık	Kullanıcı profilini günceller, sayfayı yeniler, eski veriyi görür	"Kendi yazdığını oku" yönlendirmesi; arayüzü asenkronluğa göre tasarlama
Hata ayıklama zorluğu	Hata, sebebinden üç servis ötede görünür	Yayılan bağlamla uçtan uca izleme; metrikleri izlere bağlayan exemplar'lar
Operasyonel yük	15 servis × (pipeline + pano + alarm + nöbet)	Gerçek bir platform katmanı; servis şablonları; altın yollar
Maliyet	Servis başına çoğaltılan atıl kapasite	Agresif boyutlandırma; düşük trafikli servislerde sıfıra ölçekleme

Retry fırtınaları özel dikkat hak eder. Zorlanan bir servis her çağırandan otomatik yeniden deneme aldığında, tam da kaldıramayacağı anda daha fazla yük alır. Yeniden denemeyi daima devre kesici ve jitter'lı geri çekilmeyle birleştirin; idempotent olmayan işlemleri bir idempotency anahtarı olmadan asla yeniden denemeyin.

7. Platform, dağıtım ve service mesh sorusu

Konteyner orkestrasyonu. Kubernetes ölçekte varsayılandır, ancak operasyonel yükü gerçektir. Küçük bir ekiple ve yaklaşık 15 servisin altında, yönetilen konteyner platformları (Cloud Run, ECS Fargate, App Runner, Azure Container Apps) değerin çoğunu bilişsel yükün çok azıyla verir. Kubernetes'i özgeçmiş değeri için değil, genişletilebilirliğine ihtiyacınız olduğunda seçin.

Service mesh. Istio, Linkerd ve Consul; mTLS, yeniden deneme, trafik kaydırma ve altın sinyal telemetrisini uygulama kodunu değiştirmeden sağlar. Aynı zamanda bir kontrol düzlemi, pod başına bir sidecar ve yeni bir hata sınıfı ekler. Makul eşik: ~20 servisten sonra mesh benimseyin; evrensel mTLS gerektiren bir uyum zorunluluğu varsa daha erken. Altında kütüphane düzeyinde yaklaşım genellikle daha ucuzdur.

Kod olarak altyapı. Pazarlığa kapalı. Her ortam Terraform/OpenTofu/Pulumi ile tanımlanmış, pull request'te gözden geçirilmiş, pipeline tarafından uygulanmış olmalı. Dağıtık bir sistemde manuel konsol değişiklikleri, ortamların sessizce ayrışma yoludur.

8. Geçiş sırasında güvenlik ve uyum

Ayrıştırma saldırı yüzeyinizi katlar: her servis yeni bir ağ uç noktası, yeni bir kimlik bilgisi kümesi ve yeni bir denetim sınırıdır. Bunu geçişten sonra değil, geçiş sırasında ele alın.

Servisler arası Sıfır Güven. Servisten servise çağrıları mTLS veya imzalı token'larla doğrulayın. Ağdaki konum kimlik değildir.
Merkezî sır yönetimi. Vault, AWS Secrets Manager veya GCP Secret Manager ile kısa ömürlü dinamik kimlik bilgileri. Depoya işlenmiş ortam değişkenlerinde sır yok, uzun ömürlü statik anahtar yok.
Yetkilendirme bağlamını yeniden türetmeyin, taşıyın. İmzalı bir kimliği aşağı akışa aktarın ve her sekmede doğrulayın. Bir iç çağıranın "kim" iddiasına doğrulamadan asla güvenmeyin.
Sınıra göre veri ikametgâhı. Suudi Arabistan NCA ECC, Türkiye KVKK veya Kanada PIPEDA gibi rejimlerde servis sınırları, düzenlemeye tabi verinin fiziksel olarak nerede yaşadığını belirler. Sınırları, düzenlemeye tabi veri uyumlu bir bölgeye dağıtılabilen az sayıda serviste kapsanacak şekilde tasarlayın — uyum kısıtının mimariyi fiilen iyileştirdiği ender ve değerli bir durumdur.
Güvenliği sola kaydırın. Her pipeline'da SAST, SCA, sır taraması ve konteyner imaj taraması. On beş servis, on beş bağımlılık ağacı demektir.

9. Conway Yasası ve ekip topolojileri

"Organizasyonlar, kendi iletişim yapılarını yansıtan sistemler tasarlar." — Melvin Conway, 1967

Bu bir slogan değil, ampirik bir kısıttır. Katmanlı bir ekip yapısı (frontend ekibi, backend ekibi, DBA ekibi) şemanız ne derse desin katmanlı bir mimari üretir; çünkü katmanlar arası her değişiklik ekipler arası koordinasyon gerektirir ve ekipler bundan kaçınmak üzere optimize olur.

Akışa hizalı (stream-aligned) ekiplere yeniden yapılanın: bir sınırlı bağlamı uçtan uca sahiplenen — arayüz, servis, veri, nöbet. Bunları, ürünü geliştirici deneyimi olan bir platform ekibiyle destekleyin: altın yol şablonları, CI/CD, gözlemlenebilirlik varsayılanları, ortam sağlama. Yetenek inşa edip sonra çekilen geçici uzmanlar olarak etkinleştirici ekipler ekleyin.

Bunu dürüst tutan kural: inşa eden çalıştırır. Servisi için nöbet tutmayan bir ekip o servisin güvenilirliğini önceliklendirmez ve hiçbir süreç bu teşvikin yerini tutmaz.

10. Gerçekçi 12 aylık yol haritası

Aşama	Zaman	Odak	Çıkış kriteri
0 — Hazırlık	Ay 1–2	Gözlemlenebilirlik, CI/CD, IaC, DORA temeli	Tek komutla dağıtım + geri alma; tüm uç noktalarda izleme
1 — Keşif	Ay 2–3	Event storming, bağlaşım analizi, hedef mimari	Onaylanmış bağlam haritası ve çıkarma sırası
2 — Modülerleştirme	Ay 3–5	CI'da zorunlu kılınan modül sınırları	Sıfır modüller arası DB erişimi; uygunluk testleri yeşil
3 — İlk çıkarma	Ay 5–7	Uçtan uca tek düşük riskli çevresel servis	Servis üretimde, sahibi ve nöbeti var, SLO'ları tutuyor
4 — Çekirdek alanlar	Ay 7–11	Veri ayrıştırma dahil 3–5 yüksek değerli servis	Outbox + mutabakat çalışıyor; eski yollar silindi
5 — Platform sağlamlaştırma	Ay 11–12	Servis şablonları, gerekiyorsa mesh, maliyet ayarı	Yeni servis bir günden kısa sürede ayağa kalkıyor

İki dürüst not. Birincisi: monolit hiçbir zaman tamamen kaybolmayabilir — ve bu kabul edilebilir bir sonuçtur. Değişmeyen işlevleri sunan kararlı, iyi anlaşılmış bir çekirdeğin etrafında üç dört yüksek hızlı servis bulunması meşru bir denge durumudur. Son %20'yi çıkarmak çoğu zaman getirisinden fazlasına mal olur. İkincisi: bir tedarikçinin bundan kısa sunduğu her takvime, özellikle düzenlemeye tabi iş yüklerinde, şüpheyle yaklaşın.

11. Dikkat edilmesi gereken anti-desenler

Dağıtık monolit — birlikte dağıtılmak zorunda olan servisler. Bir sürüm üç servisin koordinasyonunu gerektiriyorsa, özerklik olmadan dağıtım yapmışsınızdır. Testi şudur: her servis cuma öğleden sonra tek başına dağıtılabilir mi?
Nanoservisler — veritabanı tablosu başına bir servis. Sınırlar varlıkları değil, iş yeteneklerini izler.
Varlık servisleri — yalnızca CRUD yapan bir "Müşteri Servisi", iş mantığını orkestratörlere iter ve uyumu (cohesion) tüketir.
Bağlaşım olarak paylaşılan kütüphaneler — her servisin aynı anda yükseltmek zorunda olduğu ortak bir kütüphane, kaçtığınız sürüm trenini geri getirir. Protokolleri ve sözleşmeleri paylaşın; küçük miktarda kodu suçluluk duymadan çoğaltın.
Silme olmadan geçiş — eski ve yeni yolları süresiz çalıştırmak maliyeti ikiye katlar, güveni yarıya indirir. Her çıkarma görevi bir silme commit'iyle biter.
Tek seferde yeniden yazım — sektörümüzün en uzun belgelenmiş başarısızlık biçimi.

Sık sorulan sorular

Monolitten mikroservislere geçiş ne kadar sürer? Orta ölçekli bir kurumsal uygulamada kararlı hedef duruma ulaşmak 12–24 ay sürer; ilk çıkarılan servis genellikle 5.–7. ay civarında üretime girer. Tam geçişi bir çeyrekte vaat eden ya çok küçük bir sistemle çalışıyordur ya da veri ayrıştırmayı hesaba katmıyordur.

Kesintisiz geçiş mümkün mü? Evet. Strangler fig yönlendirme, gölge trafik, çift yazma ve kademeli yayın tam olarak kesintisiz geçiş için tasarlanmıştır. Dikkat gerektiren tek adım okuma cutover'ıdır; bu da bakım penceresi yerine anlık geri alınabilen bir feature flag arkasında olmalıdır.

Yeni bir ürüne mikroservislerle mi başlamalıyız? Genellikle hayır. Modüler monolitle başlayın. Erken aşama ürünler alan sınırlarını sık değiştirir; bir sınırı tek süreç içinde taşımak refaktör, servisler arasında taşımak ise projedir. Ölçekleme, ekip özerkliği veya patlama yarıçapı gibi somut bir kısıt gerektirdiğinde servis çıkarın.

Başarısızlığın en büyük nedeni nedir? Gözlemlenebilirlik, dağıtım otomasyonu ve net servis sahipliği olmadan geçişe kalkışmak. Genellikle mimari değil, işletim modeli çöker.

Kaç mikroservisimiz olmalı? Hedef bir sayı yoktur ve size sayı veren danışmanı dikkate almayın. İşlevsel ölçüt: bir servis tek ekip tarafından sahiplenilebilir, yeni bir mühendis tarafından bir hafta içinde anlaşılabilir ve bağımsız dağıtılabilir olmalıdır. Orta ölçekli kurumların çoğu yüzlerce değil, 8 ile 25 servis arasında dengelenir.

Monolite geri dönmek doğru olabilir mi? Evet ve olgun ekipler bunu yapar. Servisler hep birlikte dağıtılıyor, aynı veritabanını paylaşıyor ve tek ekip tarafından sürdürülüyorsa, birleştirmek özerklik kaybı olmadan maliyeti düşürür. Hatalı bir ayrıştırmayı geri almak başarısızlık değil, mühendislik olgunluğudur.

İlgili yazılar

Kıdemli yazılım mimarlarıyla çalışın

Legacy modernizasyonu, ürün teslimatı ile teknik hijyen arasında denge kurmayı gerektirir ve yanlış çizilmiş bir sınırın maliyeti yıllarca birikir. D-Elite Solutions mimarları; fintech, sağlık ve kurumsal SaaS alanlarında, Kanada, Körfez ve Türkiye'yi kapsayan düzenlemeye tabi ortamlarda ayrıştırma programları yönetti.

Ücretsiz Teknik İnceleme Randevusu Alın →

45 dakikada mevcut mimarinizi değerlendirir, en yüksek değerli çıkarma adaylarınızı belirler ve gerçekçi bir aşamalı yol haritası sunarız — bizimle çalışsanız da çalışmasanız da.