Tek bir uygulama, ilk günlerde işleri hızlandırır. Küçük ekip, tek kod tabanı, tek veritabanı. Yayına çıkmak kolaydır. Ancak kullanıcı sayısı arttığında, yeni modüller eklendiğinde ve ekip 5-6 geliştiriciyi geçtiğinde aynı yapı yavaşlamaya başlar. Bir modüldeki değişiklik tüm sistemi etkiler. Dağıtım pencereleri uzar. Hata ayıklamak maliyetli hale gelir.

Bu aşamada sık sorulan soru şudur: mikroservis mimarisi nedir ve gerçekten ne zaman ihtiyaç duyulur? Kısa tanımı nettir. Mikroservis mimarisi, büyük bir uygulamayı tek parça halinde kurmak yerine, bağımsız geliştirilen, ayrı dağıtılabilen ve belirli iş sorumluluklarına odaklanan küçük servisler olarak tasarlama yaklaşımıdır. Her servis kendi iş kuralını yönetir. Gerekirse kendi verisini de tutar.

Yine de büyüyen her şirkette ilk tercih mikroservis olmamalıdır. Doğru karar; trafik hacmi, ekip yapısı, yayın sıklığı, entegrasyon yükü ve operasyon kabiliyeti gibi ölçütlere göre verilir. Aşağıda konuyu teknik ama anlaşılır bir çerçevede ele alalım.

Mikroservis mimarisi nedir? Temel tanım ve çalışma şekli

Mikroservis yaklaşımında uygulama; örneğin sipariş, ödeme, kullanıcı yönetimi, bildirim ya da raporlama gibi iş alanlarına ayrılır. Her servis HTTP API, mesaj kuyruğu veya event tabanlı iletişim üzerinden haberleşir. En kritik fark şudur: Servisler birbirinden bağımsız şekilde deploy edilebilir.

Somut bir e-ticaret senaryosu düşünelim. Tek parça bir uygulamada, sepet ekranındaki küçük bir değişiklik için tüm sistem yeniden paketlenip yayınlanabilir. Mikroservis yaklaşımında ise yalnızca cart-service güncellenir. Ödeme tarafı aynı sürümde kalır. Bu da haftada 1 yerine günde 5-10 dağıtım yapan ekipler için ciddi bir operasyon avantajı sağlar.

Tipik bileşenler

  • API Gateway: İstemciden gelen istekleri uygun servislere yönlendirir.
  • Service Discovery: Dinamik ortamda hangi servisin hangi adreste çalıştığını bulur.
  • Message Broker: Kafka, RabbitMQ benzeri yapılarla asenkron iletişim kurulur.
  • Container altyapısı: Genellikle Docker ve Kubernetes ile dağıtım yönetilir.
  • Observability araçları: Log, metrik ve trace toplama zorunlu hale gelir.

Burada küçük bir kod örneği resmi daha da netleştirir:

GET /api/orders/4821
-> order-service
-> user-service
-> payment-service
-> inventory-service

İstemci tek bir uç nokta görür. Arka planda ise birden fazla servis birlikte çalışır.

Monolitten farkı nedir? Her sistem neden mikroservis olmaz?

Monolit, tüm modüllerin tek uygulama içinde çalıştığı mimaridir. Kötü bir model değildir. Hatta birçok kurum için yıllarca en doğru çözüm olabilir. 10 bin günlük aktif kullanıcısı olan bir B2B portal ile ayda milyonlarca isteği işleyen bir SaaS platformun mimari ihtiyaçları aynı değildir.

Monolitin güçlü yanları açıktır. Kurulumu hızlıdır. Yerel geliştirme daha basittir. Dağıtım zinciri daha az parçadan oluşur. Özellikle MVP aşamasında, 3-4 geliştiricilik ekipler için daha düşük operasyon yükü sağlar.

Mikroservis ise karmaşıklığı ortadan kaldırmaz; çoğu zaman yerini değiştirir. Uygulama içindeki bağımlılıkları ağ seviyesine taşır. Artık bellek içi fonksiyon çağrısı yerine ağ üzerinden istek yapılır. 20 ms süren bir işlem, başka bir servise gidince 150-300 ms aralığına çıkabilir. Ağ hataları, timeout, retry ve circuit breaker gibi başlıklar gündeme gelir.

Hangi durumda monolit daha uygundur?

  • Ürün henüz pazar doğrulama aşamasındaysa
  • Ekip 8 kişinin altındaysa ve tek backlog ile ilerliyorsa
  • Dağıtım sıklığı haftalık ya da daha seyrekse
  • Alan ayrımları netleşmediyse

Soru sadece “mikroservis iyi midir?” olmamalı. Asıl mesele şudur: İş yükünüz, organizasyon yapınız ve teknik borcunuz bu modele gerçekten hazır mı?

Büyüyen şirketlerde ölçekleme ne demektir?

Ölçekleme yalnızca daha fazla sunucu eklemekten ibaret değildir. En az 4 katmanda düşünülmelidir: trafik, veri, ekip ve teslimat süreci. Örneğin kullanıcı sayısı 50 binden 500 bine çıktığında sadece CPU kullanımı artmaz. Raporlama sorguları ağırlaşır, müşteri destek süreçleri büyür, yeni entegrasyon talepleri gelir, yayın riskleri çoğalır.

Şirketler genelde şu sinyaller ortaya çıktığında zorlanmaya başlar:

  • Build ve test süresi 10 dakikadan 45 dakikaya çıkar.
  • Tek bir release içinde 20-30 farklı modül değişir.
  • Bir hata tüm uygulamayı etkiler.
  • Belirli modüller diğerlerinden 5 kat fazla trafik alır.
  • Farklı ekipler aynı kod alanında çakışır.

Bu noktada mikroservis mimarisi, özellikle farklı hızlarda büyüyen modülleri ayrı ölçekleme imkânı sunduğu için öne çıkar. Ödeme servisi saniyede 200 istek alırken raporlama servisi saat başı yoğunluk yaşayabilir. Tek parça mimaride ikisi birlikte büyür. Mikroserviste ise yalnızca ihtiyaç duyan servis çoğaltılır.

Mikroservis ile yazılım ölçekleme nasıl yapılır?

Başarılı ölçekleme, sadece “uygulamayı bölmekle” tamamlanmaz. Önce doğru servis sınırları çizilir. Domain-driven design yaklaşımındaki bounded context mantığı burada işe yarar. Sipariş yaşam döngüsü ile muhasebe mutabakatı aynı serviste olmak zorunda değildir.

1) İş alanlarına göre bölme

Teknik katmanlara göre ayırmak yaygın bir hatadır. “Frontend servisi, backend servisi, database servisi” mikroservis tasarımı değildir. Doğru yaklaşım, iş kabiliyetlerini ayırmaktır. Örnek bir B2B sipariş platformunda şu servisler düşünülebilir:

  • müşteri hesabı
  • fiyatlandırma
  • stok uygunluğu
  • sipariş yönetimi
  • fatura ve tahsilat
  • bildirim

Bu yapı, ekiplerin birbirinden bağımsız hareket etmesini kolaylaştırır.

2) Veritabanını dikkatli ayrıştırma

En zor adımlardan biri budur. Her mikroservisin tek ve ortak bir veritabanını paylaşması, bağımsızlığı sınırlar. İdeal modelde servis kendi veri sahipliğine sahiptir. Yine de bu geçiş bir gecede tamamlanmaz. Sık kullanılan yöntemlerden biri, önce tablo bazlı sahiplik tanımlamak, ardından servis bazlı veri izolasyonuna geçmektir.

Gerçekçi bir geçiş planında, 3 ay boyunca bazı read işlemleri ortak veritabanından yapılırken write işlemleri yeni servise taşınabilir. Bu hibrit dönem normaldir.

3) Senkron yerine uygun yerde asenkron akış kurma

Her şeyi API çağrısı ile yapmak sistemi kırılgan hale getirir. Sipariş oluşturulduktan sonra e-posta gönderimi veya ERP entegrasyonu anlık olmak zorunda değildir. Event tabanlı akış burada avantaj sağlar:

OrderCreated
-> billing-service faturayı hazırlar
-> notification-service e-posta kuyruğuna yazar
-> erp-adapter siparişi dış sisteme iletir

Böylece bir entegrasyon geciktiğinde sipariş ekranı tamamen çökmez.

4) Otomasyon ve gözlemlenebilirlik ekleme

5 servisten sonra manuel takip zorlaşır. 15 servis olduğunda merkezi loglama, dağıtık iz sürme ve alarm mekanizmaları lüks değil, ihtiyaç haline gelir. En azından şu veriler izlenmelidir:

  • p95 ve p99 yanıt süreleri
  • hata oranı
  • servis başına CPU ve bellek kullanımı
  • mesaj kuyruğu gecikmesi
  • başarısız dağıtım sayısı

Örneğin p95 yanıt süresi 180 ms olan bir servis, yeni sürüm sonrası 620 ms seviyesine çıkıyorsa sorun release anında fark edilir. Aksi durumda kullanıcı şikâyetini beklemek gerekir.

Geçiş stratejisi: Monolitten mikroservise bir anda çıkılmaz

Kurumsal projelerde en büyük hatalardan biri, tüm sistemi baştan yazmaya kalkmaktır. Risk yüksektir. Süre uzar. İş tarafı değer görmeden aylar geçebilir. Daha güvenli yöntem ise aşamalı ayrıştırmadır.

Strangler Fig yaklaşımı

Bu modelde mevcut monolit çalışmaya devam eder. Yeni işlevler ya da yoğun kullanılan bir alan dışarı alınır. Trafik kademeli olarak yönlendirilir. Örneğin ilk etapta yalnızca bildirim servisi ayrılır. Ardından kullanıcı yönetimi gelir. Sonra sipariş akışı ayrıştırılır.

6-9 aylık bir dönüşüm planında tipik sıra şöyle olabilir:

  1. Dış entegrasyonları adaptör katmanına almak
  2. API gateway eklemek
  3. Düşük riskli modülü ayırmak
  4. CI/CD hattını servis bazlı çalıştırmak
  5. Veri sahipliğini netleştirmek

Böyle bir geçişte başarı ölçütü sadece “kaç servis yazıldı” değildir. Dağıtım süresi kısaldı mı? Hata alanı daraldı mı? Ekipler birbirini beklemeden ilerleyebiliyor mu? Asıl yanıt burada aranır.

Sık görülen hatalar ve teknik riskler

Mikroservis mimarisi doğru uygulandığında güçlüdür. Yanlış uygulandığında ise dağınık bir sistem ortaya çıkarır. Sık karşılaşılan sorunlar nettir.

  • Aşırı parçalama: 2-3 modüllük sistemi 20 servise bölmek operasyon yükünü gereksiz yere artırır.
  • Paylaşımlı veritabanı bağımlılığı: Servisler kağıt üstünde ayrı görünür, gerçekte ise tek sistem gibi kalır.
  • Yetersiz DevOps olgunluğu: Otomatik test, container yönetimi ve rollback yoksa dağıtım riski büyür.
  • Dağıtık transaction beklentisi: Her serviste ACID tutarlılık aramak tasarımı zorlar. SAGA gibi desenler gerekebilir.
  • İnsan faktörünü atlamak: Mimariden önce ekip sınırları ve sorumluluklar netleşmelidir.

Özellikle 7/24 çalışan sistemlerde timeout, retry limitleri ve idempotency anahtarları tasarımın merkezinde yer almalıdır. Aynı ödeme isteğinin iki kez işlenmesi sadece teknik bir hata değil, doğrudan iş riski yaratır.

Hangi şirketler için doğru zaman?

Kesin bir çalışan sayısı ya da trafik eşiği vermek doğru olmaz. Yine de bazı pratik göstergeler karar vermeyi kolaylaştırır. Eğer bir ürün ekibi aynı anda web, mobil, bayi paneli, ERP entegrasyonu ve raporlama ihtiyaçlarını taşıyorsa; release takvimi çatışıyorsa; farklı modüller belirgin biçimde farklı ölçek ihtiyaçları doğuruyorsa mikroservis mantıklı bir seçenek haline gelir.

Buna karşılık tek ürün, sınırlı kullanıcı kitlesi ve düşük değişim temposu olan yapılarda iyi tasarlanmış bir modüler monolit çoğu zaman daha sağlıklı olur. Gereksiz mimari karmaşıklık yerine alan modelini düzgün kurmak, test otomasyonunu güçlendirmek ve API tasarımını temiz tutmak daha fazla değer üretir.

Özetle, mikroservis mimarisi bir hedef değil; büyüme baskısına verilen teknik bir yanıttır. Doğru zamanda seçildiğinde ekiplerin bağımsız çalışmasını, servislerin ayrı ölçeklenmesini ve yayın süreçlerinin hızlanmasını sağlar. Erken tercih edildiğinde ise operasyon maliyetini artırabilir. En iyi yaklaşım, mevcut sistemi, iş akışlarını ve büyüme planını birlikte değerlendirip kademeli bir mimari yol haritası çıkarmaktır.