Microservices hataları çoğu zaman servis sayısından önce karar ve boundary tasarımında başlar. Ayrı deployment, tek başına daha düşük coupling veya daha yüksek dayanıklılık sağlamaz. Veri erişimi, çağrı zinciri ve operasyon sorumlulukları aynı sınırı desteklemiyorsa dağıttığımız şey eski bağımlılıklar olabilir.
Geçişi mevcut darboğazla ilişkilendirmek gerekir; aksi halde ek network ve tutarlılık maliyetinin hangi ihtiyacı karşıladığını ölçemeyiz.
Bu yazıda, gerçek projelerde defalarca gördüğüm yedi hatayı ele alıyorum. Her biri için önce hangi bağımlılığı oluşturduğuna, sonra hangi koşulda farklı bir karar gerektiğine bakıyorum.
1. İhtiyacı tanımlamadan başlamak
“Biz de Microservices yapalım” tek başına bir business veya operasyon hedefi değildir. Ayrılacak capability’nin bağımsız release, kapasite, teknoloji veya failure isolation ihtiyacını belirleyin. Microservices’in zorunluluk olması gerekmez; faydası ek işletim maliyetini karşılayan bir seçenek olması gerekir.
Önce geçiş sinyallerini mevcut sistemde ölçün. Codebase’in büyüklüğüyle başlamak yerine hangi değişikliğin hangi release’i veya SLO’yu etkilediğini çıkarın.
2. Domain boundary’yi process sınırı sanmak
Bir sınıf grubunu ayrı servise taşımak, onun bağımsız business sorumluluğu olduğu anlamına gelmez. Sık birlikte değişen iki parçayı ayırırsanız contract ve deployment koordinasyonu devam edebilir. Çok sayıda senkron çağrı da eski coupling’i network yoluna taşır.
Distributed monolith, tek deployment biçiminden çok bu koordinasyon yükünü anlatır. Domain Boundary tasarımını önce iş sorumluluğu ve veri sahipliği üzerinden netleştirin.
3. Private tabloları ortak model haline getirmek
Aynı fiziksel database server’ını kullanmakla aynı tabloları birlikte yönetmek farklı kararlardır. Ayrı schema veya private table set’leri erişim kurallarıyla sınır koyabilir. Ancak servisler birbirinin private kolonlarına bağlanıyorsa migration ve deployment koordinasyonu artar.
Verinin sahibini, dış read/write contract’ını ve desteklenen schema değişikliklerini belirleyin. Reporting için ayrı projection gerekebilir; bu ihtiyacı private tabloya sınırsız erişimle çözmeyin. Data Ownership rehberi bu seçeneklerin maliyetini ele alıyor.
4. Network çağrısını local method call gibi ele almak
Uzak çağrı serialization, latency ve partial failure ekler. Bu durum her Microservices sisteminin kırılgan olduğu anlamına gelmez; çağrı yolunun hata davranışını ayrıca tasarlamak gerekir. Monolith de database veya dış API gibi uzak bağımlılıklar taşıyabilir.
Timeout bütçesini bütün request zincirinde belirleyin. Geçici hatalarda sınırlı retry kullanın; backoff/jitter ve toplam deneme süresini dikkate alın. İlk işlem başarıyla tamamlanıp response kaybolduysa retry aynı yazmayı tekrarlayabilir, bu yüzden idempotency kritik hale gelir. Retry pattern’i bu sınırı açıklıyor.
Circuit Breaker, sürekli başarısız bir bağımlılığa çağrıları geçici olarak keser. Business tutarlılığını veya yanlış service boundary’yi kendiliğinden düzeltmez.
5. Observability sorumluluğunu sonraya bırakmak
Monolith’te de async işler ve dış çağrılar nedeniyle tek stack trace yeterli olmayabilir. Dağıtık akışta logları ve trace context’i birlikte taşımazsanız bir user request’inin hangi serviste beklediğini bulmak daha fazla manuel iş gerektirir.
Request correlation, structured logging, tracing ve servis/dependency metriklerini extraction öncesinde kurun. SLO ve alarm sorumluluğunu belirleyin; dashboard sayısını gözlemlenebilirliğin kanıtı saymayın. Microsoft’un mimari değerlendirmesi test ve operasyon maliyetini birlikte ele alıyor.
6. Ownership ve işletim kapasitesini varsaymak
Microservices’in teknik ve organizasyonel boyutları birlikte çalışır. Servisin feature geliştirmesini bir ekip üstlenirken deployment, alarm ve olay müdahalesi sahipsiz kalıyorsa bağımsızlık eksiktir.
Ekip sayısı için tek bir eşik yoktur. Bunun yerine CI/CD, rollback, contract compatibility ve on-call sorumluluklarını değerlendirin. Managed platform altyapı işini azaltabilir; ancak business operasyonu ve veri tutarlılığı sorumluluğunu ortadan kaldırmaz.
7. Cutover ve rollback planı olmadan toplu geçiş yapmak
Big bang migration, aynı anda değiştirdiğiniz parçaların kapsamını ve geri dönüş maliyetini artırabilir. Bununla birlikte Strangler Fig her sistemde tek doğru seçenek değildir. Uygun routing/interception noktası, eski/yeni data ownership ve güvenli fallback şartlarını inceleyin.
Aşamalı geçişte de plansız dual write, drift veya kayıp değişiklik oluşturabilir. Backfill’i, devam eden yazıları ve cutover sonrası authoritative tarafı belirleyin. Strangler Fig pattern’i eski sistemi çalışır tutarken yeni parçaya geçişin sınırlarını açıklıyor.
Microservices hataları için karar ve doğrulama
Bu Microservices hataları, yanlış tanımlanmış bir ihtiyacın yanında teknik uygulama ve operasyon eksiklerinden de doğabilir. Service sayısını artırmak başarı ölçütü değildir. Önce tek bir capability’de release süresi, hata oranı ve gecikme değişimini ölçün; fayda ortaya çıkmıyorsa ayrımı genişletmeyin.
Tercihim, Modular Monolith içinde çalışan boundary ve data ownership’i önce görünür kılmak. Belirli bir parçanın ayrı deployment ihtiyacı güçlendiğinde onu ayırmak, dağıtım maliyetini kontrol etmeyi kolaylaştırır.
