Küçük Projeye Neden Kafka ve Mikroservis Kurulmaz? (Over-Engineering Yanılgısı)

Yeni bir projeye başlarken hemen hepimizin düştüğü tatlı bir tuzak vardır: Henüz tek bir aktif kullanıcısı bile olmayan bir uygulamayı, sanki yarın sabah 10 milyon kişi hücum edecekmiş gibi tasarlamaya kalkışmak.

Mimari şemaya bakarız; 12 ayrı mikroservis, arada asenkron event'ler için bir Apache Kafka kümesi, her servisin kendi bağımsız veritabanı, aralara gRPC iletişim protokolü, servisleri ayağa kaldırmak için de devasa bir Kubernetes konfigürasyonu...

Kulağa LinkedIn'de hava atılabilecek "büyük mühendislik" gibi gelir. Ancak acı gerçek şudur: Günde 100 kişinin girdiği bir projeye Kafka ve mikroservis kurmak mühendislik değil; projeyi daha doğmadan öldürmektir.

1. "Netflix de Böyle Yapıyor" Efsanesi

Bu yanılgının en büyük sebebi, dev teknoloji şirketlerinin blog yazılarını kendi bağlamımızdan kopararak okumamızdır.

Unutulan şey şu: Netflix, Uber veya Amazon ilk gün mikroservis mimarisiyle başlamadı.

• Netflix, devasa bir monolit yapıyı 2008 yılındaki büyük veritabanı çöküşüne kadar yıllarca başarıyla çalıştırdı. Mikroservislere geçişlerinin sebebi "teknolojinin havalı olması" değil, binlerce mühendisin aynı kod tabanında birbirinin ayağına basması ve tek bir veritabanının fiziksel donanım sınırlarına dayanmasıydı.
• Shopify, dünyanın en büyük e-ticaret trafiğini hâlâ tek bir devasa Modular Monolith (Ruby on Rails) üzerinde yönetiyor.

Eğer 2-3 kişilik bir ekiple (veya tek başına) bir ürün geliştiriyorsan; senin asıl düşmanın veritabanının saniyede 100.000 transaction kaldıramaması değildir. Senin asıl düşmanın pazara geç çıkmak, geliştirdiğin özellikleri canlıya alamamak ve zamanını mimarinin getirdiği bürokrasiyi tamir etmeye harcamaktır.

2. Erken Dağıtık Sistemin Gizli Maliyeti

Tek bir monolit uygulamada bir fonksiyon çağırmak (await orderService.createOrder()) nanosaniyeler sürer, bellekte gerçekleşir ve başarısız olursa tek bir veritabanı transaction'ı (ROLLBACK) ile her şey eski haline döner.

Mikroservise ve Kafka'ya geçtiğin anda kucağına şu problemler düşer:

1. Dağıtık Transaction Krizleri (Two-Phase Commit / Saga): Kullanıcının parası çekildi ama fatura servisi çöktü. Şimdi ne olacak? Parayı nasıl iade edeceksin?
2. Ağ Gecikmesi (Network Latency): Eskiden bellek içinde milisaniyenin altında çalışan kod, artık sunucular arası HTTP/gRPC istekleriyle 20–50 kat daha yavaş çalışır.
3. Observability (Gözlemlenebilirlik) Cehennemi: Bir hata olduğunda hatanın hangi serviste, hangi kuyrukta, hangi consumer'da kaybolduğunu bulmak için OpenTelemetry, Jaeger ve merkezi log altyapıları kurup yönetmek zorunda kalırsın.
4. Deploy Felçliği: Tek komutla sunucuya çıkmak yerine; servis bağımlılıkları, Docker registry'leri ve CI/CD pipeline'larıyla boğuşursun.

3. Adım Adım Backend Ölçekleme Piramidi

Peki doğrusu nedir? Kullanıcı sayımız arttıkça altyapıyı ne zaman ve hangi sırayla büyütmeliyiz?

      ▲
     / \     Aşama 4: 1M+ DAU & Çoklu Ekipler
    /   \    ➔ Event-Driven (Kafka), K8s, Mikroservisler
   /-----\   
  /       \   Aşama 3: 250k - 1M DAU
 /         \  ➔ Read-Replicas, Async Queue (BullMQ, RabbitMQ)
/-----------\ 
/             \ Aşama 2: 50k - 250k DAU
/               \ ➔ Redis Cache (Cache-Aside), Connection Pooling (PgBouncer)
/-----------------\
/                   \ Aşama 1: 0 - 50k DAU
/                     \ ➔ Modular Monolith + Tek Bir PostgreSQL

1. Aşama: 0 – 50.000 DAU (Clean Modular Monolith)

• Mimari: Tek bir Node.js (Fastify/NestJS), Go veya Python monoliti.
• Veritabanı: Tek bir Managed PostgreSQL veya MySQL.
• Strateji: Kodunu spaghetti yazma; modüllere (domain'lere) ayır. Yarın ayırman gerekirse sınırları belli olsun ama aynı süreç (process) içinde çalışsın. Bu yapı seni günde on binlerce aktif kullanıcıya kadar hiçbir darboğaz yaşamadan taşır.

2. Aşama: 50.000 – 250.000 DAU (Önbellek & Havuz)

• Sorun: Veritabanı CPU'su aynı sorguların tekrar tekrar çalıştırılmasından dolayı yükselmeye başlar.
• Çözüm:
  • Veritabanının önüne Redis (Cache-Aside Pattern) ekle. Sık okunan veriyi RAM'den 1–2 milisaniyede dön.
  • Veritabanı bağlantılarını optimize etmek için PgBouncer / Connection Pool kur.

3. Aşama: 250.000 – 1.000.000 DAU (Okuma/Yazma Ayrımı & Arka Plan İşleri)

• Sorun: E-posta gönderme, PDF oluşturma veya görsel işleme gibi ağır işler ana API isteklerini tıkamaya başlar. Okuma istekleri veritabanını zorlar.
• Çözüm:
  • Ağır işleri API'den koparıp BullMQ veya RabbitMQ gibi hafif bir kuyrukla arka plan worker'larına devret.
  • Veritabanına 1–2 adet Read-Replica ekle. Okuma sorgularını replikalara, yazmaları (write) ana makineye yönlendir.

4. Aşama: 1.000.000+ DAU (Dağıtık Mimariler & Kafka)

• Neden şimdi? Artık tek bir ekibin yönetemeyeceği kadar çok bağımsız ekip (Payments ekibi, Search ekibi, Auth ekibi) vardır ve veritabanı boyutu terabaytlarca event üretmektedir.
• Çözüm: İşte Kafka, Event-Driven Architecture ve bağımsız mikroservisler tam olarak bu noktada bir zorunluluk haline gelir.

Karar Vermekte Zorlanıyor musun?

Kendi projende şu an hangi aşamada olduğunu, ne zaman kuyruk eklemen gerektiğini ve hangi teknolojileri tercih etmen gerektiğini adım adım test edebileceğin interaktif bir karar matrisi hazırladım:

👉 İnteraktif Backend Ölçekleme Karar Tablosu'nu İncele

Özet

En iyi mimari, en çok araç kullanan mimari değildir. En iyi mimari, iş hedeflerine en az karmaşıklıkla ve en yüksek geliştirici hızıyla ulaşan mimaridir.

İlk gün Kafka ve Kubernetes kurarak harcayacağın 2 ayı, ürününün kullanıcı deneyimini mükemmelleştirmeye harca. Kodunu temiz bir monolit olarak tasarla; trafiğin geldiğinde sistemi büyütmek sandığından çok daha keyifli ve yönetilebilir olacaktır.