Mikroservis mi Monolit mi? Doğru Mimari Seçimi

Kısa cevap: projelerin büyük çoğunluğu için doğru başlangıç, iyi bölümlenmiş bir monolittir (modüler monolit). Mikroservis mimarisi; birbirinden bağımsız yayın yapması gereken birden fazla ekip, çok farklı ölçeklenme ihtiyacı olan parçalar ya da ayrı tutulması zorunlu alanlar varsa anlam kazanır. Bu koşullar yokken mikroservise geçmek, sorunu çözmeden işletme maliyetini katlar.

Monolit ve mikroservis nedir?

Monolit, uygulamanın tek bir kod tabanı olarak derlenip tek parça hâlinde yayınlandığı mimaridir; sipariş, stok ve fatura modülleri aynı süreçte çalışır ve genellikle aynı veritabanını kullanır. Mikroservis mimarisinde ise her iş alanı ayrı bir servistir: kendi kodu, kendi veritabanı ve kendi yayın takvimi vardır; servisler birbirleriyle ağ üzerinden, API çağrıları veya mesaj kuyrukları aracılığıyla konuşur.

Arada üçüncü ve çoğu zaman en mantıklı seçenek vardır: modüler monolit. Kod tek parça yayınlanır ama içeride modüller net sınırlarla ayrılır; bir modül diğerinin tablosuna doğrudan dokunmaz, yalnızca tanımlı arayüzü üzerinden konuşur. İleride bir modülü ayrı servise çıkarmak gerekirse sınır zaten çizilmiştir.

Mikroservis mi monolit mi: karşılaştırma

• Geliştirme hızı: başlangıçta monolit çok daha hızlıdır; mikroservis her yeni özellikte servisler arası sözleşme ister.
• Yayın: monolitte tek yayın hattı vardır; mikroserviste her servisin kendi hattı, sürümü ve geri alma planı olur.
• Ölçeklenme: monolit bütün olarak çoğaltılır; mikroserviste yalnızca yük altındaki parça büyütülür.
• Hata ayıklama: monolitte tek log ve tek yığın izi yeterlidir; mikroserviste merkezi log ve dağıtık izleme şarttır.
• Veri tutarlılığı: monolitte tek veritabanı işlemi yeter; mikroserviste servisler arası tutarlılık ayrıca tasarlanır.
• İşletme maliyeti: mikroservis daha fazla sunucu, izleme aracı ve DevOps emeği gerektirir.

Mikroservis bir ölçeklenme tekniğinden önce bir organizasyon tekniğidir: asıl çözdüğü sorun, birbirini bekleyen ekiplerdir. Tek ekipli bir projede bu sorun yoktur.

Mikroservisin gizli maliyetleri

Mikroservis mimarisi kâğıt üzerinde esnek görünür; faturası sonradan gelir. Monolitte bir fonksiyon çağrısı olan iş, mikroserviste ağ çağrısına dönüşür ve artık zaman aşımına uğrayabilir, yavaşlayabilir ya da yarıda kalabilir. "Siparişi oluştur, stoğu düş, faturayı kes" gibi tek veritabanı işleminde güvenle yapılan bir akış, üç servis arasında telafi adımlarıyla yeniden tasarlanmak zorunda kalır.

• Her servis için ayrı yayın hattı, izleme, alarm ve yedekleme kurulumu.
• Servisler arası sürüm uyumu: bir API değişikliği birden fazla servisi aynı anda etkiler.
• Dağıtık izleme ve merkezi log altyapısı olmadan hatanın hangi serviste olduğunu bulmak saatler sürer.
• Yerel geliştirme ortamı ağırlaşır; bir özelliği denemek için beş servisi birden ayağa kaldırmak gerekir.

Servis sayısı arttıkça otomatik test ve yayın hattı zorunlu hâle gelir; elle yayın yapılan bir mikroservis sistemi yönetilemez. Bu altyapının nasıl kurulduğunu CI/CD nedir yazımızda anlattık.

Modüler monolit pratikte nasıl görünür?

Modüler monolitte her iş alanı kendi klasöründe durur ve dışarıya yalnızca küçük bir arayüz açar. Aşağıdaki TypeScript örneğinde sipariş modülü stok tablosuna doğrudan erişmez; stok modülünün yayımladığı fonksiyonu çağırır. Yarın stok ayrı bir servise taşınırsa değişen tek şey bu arayüzün arkasındaki uygulama olur.

// modules/inventory/index.ts — modülün dışarıya açtığı tek kapı
export interface InventoryApi {
  reserve(productId: string, qty: number): Promise<boolean>;
}

// modules/orders/createOrder.ts
import type { InventoryApi } from '../inventory';

export async function createOrder(
  inventory: InventoryApi,
  productId: string,
  qty: number,
) {
  const ok = await inventory.reserve(productId, qty);
  if (!ok) throw new Error('Yetersiz stok');
  // sipariş kaydı yalnızca orders modülünün tablolarına yazılır
}

Bu disiplin, bir kural aracıyla (örneğin modüller arası import kısıtlaması) otomatik denetlenebilir. Böylece monolit, zamanla her şeyin her şeye bağlı olduğu "büyük çamur topuna" dönüşmez.

Mikroservise ne zaman geçilmeli?

• Aynı kod tabanında çalışan ekipler birbirinin yayınını bekliyor ve bu kronik bir darboğaz.
• Bir modülün yükü diğerlerinden katlarca fazla (örneğin raporlama veya görsel işleme) ve tüm sistemi onunla birlikte büyütmek pahalı.
• Bir alanın farklı güvenlik, uyum ya da teknoloji gereksinimi var (örneğin ödeme verisi veya yapay zekâ işleri).
• Modül sınırları oturmuş; hangi verinin kime ait olduğu artık tartışma konusu değil.

Geçiş tek seferde yapılmaz. En sağlıklı yol, sınırı en net ve baskısı en yüksek modülü tek başına ayırmak, trafiği kademeli olarak yeni servise yönlendirmek ve sonucu ölçtükten sonra bir sonrakine geçmektir. Yeni bir ürüne başlıyorsanız mimariyi baştan ağırlaştırmak yerine MVP nedir yazımızdaki yaklaşımla önce ürünün tuttuğunu görmek daha doğru olur; çok kiracılı bir üründe bu kararları SaaS ürünü nasıl geliştirilir yazısında ayrıca ele aldık.

Sonuç

Mikroservis mi monolit mi sorusunun cevabı moda değil, ekip yapısı ve yük profilidir. Çoğu şirket için doğru sıra şudur: modüler monolitle başla, sınırları temiz tut, gerçek bir darboğaz ortaya çıktığında yalnızca o parçayı ayır. Özel yazılım ve kurumsal çözümler projelerimizde mimariyi bugünün ihtiyacına göre kurup yarının büyümesine yer bırakıyoruz. Projeniz için doğru mimariyi birlikte belirlemek isterseniz teklif alın.