Backend Ölçekleme Karar Tablosu (0'dan Milyon Kullanıcıya)

Konu konu

Haritadaki her konunun açıklaması, bilmen gerekenler ve kaynaklar — tek listede.

1. 011. Aşama: Temiz Modular Monolith (0 - 50K DAU)

   • Modular Monolith Mimarisi· Temel+

     Fastify, NestJS, Go veya Django ile domain sınırları klasör bazında izole edilmiş tek bir monolit kur. Modüller arası iletişim RPC veya network üzerinden değil, doğrudan bellek içi fonksiyon çağrısıyla yapılır (0ms gecikme).

     Bilmen gerekenler

     • Modüller birbirinin veritabanı tablosuna doğrudan dokunmaz; public fonksiyon/servis arayüzü üzerinden konuşur.
     • Tek bir sunucu ve doğru indekslenmiş PostgreSQL ile 3,500+ istek/saniye (RPS) rahatlıkla kaldırılır.
     • Tek Docker imajı ve tek CI/CD hattı ile deploy süreçleri saniyeler içinde tamamlanır.

     Kaynaklar

     • System Design Primer· Rehber
   • Veritabanı İndeksleri & Bağlantı Havuzu (Pooling)· Temel+

     Yavaşlayan sistemlerin %90'ında sorun sunucunun yetmemesi değil, eksik indeksler ve tüketilen veritabanı bağlantılarıdır.

     Bilmen gerekenler

     • Tüm foreign key'lere ve sorgu WHERE / ORDER BY koşullarına B-Tree indeks ekle; EXPLAIN ANALYZE ile planı doğrula.
     • Uygulama ile veritabanı arasına PgBouncer koyarak binlerce istemciyi 50-100 aktif veritabanı bağlantısında topla.

     Kaynaklar

     • Use The Index, Luke (SQL İndeks Rehberi)· Rehber

2. 022. Aşama: Veritabanını Rahatlat (50K - 150K DAU)

   • Redis Cache-Aside Önbellekleme· Temel+

     Sık okunan fakat nadir değişen kullanıcı profili, genel ayarlar ve ana sayfa içeriklerini Redis RAM'e al (450ms disk süresinden 1.2ms RAM hızına).

     Bilmen gerekenler

     • Önce Redis'e sor; varsa doğrudan dön (Cache Hit). Yoksa veritabanından oku ve Redis'e yaz (Cache Miss).
     • Her anahtara mutlaka makul bir TTL (Time-To-Live) süresi ata; sonsuz önbellek bellek sızıntısına yol açar.

     Kaynaklar

     • Redis Cache-Aside Pattern Dokümantasyonu· Doküman
   • Read / Write Ayrımı & Read Replicas· İyi olur+

     Web uygulamalarında trafiğin %85'i okuma (SELECT), %15'i yazmadır (INSERT/UPDATE). Okuma yükünü replikalara dağıt.

     Bilmen gerekenler

     • Yazma işlemlerini Primary veritabanına, raporlama ve arama sorgularını Read Replica'ya yönlendir.
     • Replikasyon gecikmesini (replication lag) kritik kullanıcı işlemlerinde (örn. ödeme sonrası sipariş gösterme) hesaba kat.
   • CDN & Statik Varlık Dağıtımı· Temel+

     Görselleri, fontları, CSS dosyalarını ve kamuya açık API yanıtlarını Cloudflare Edge üzerinde önbellekle; sunucuya hiç uğramasın.

     Bilmen gerekenler

     • Trafik origin sunucuna ulaşmadan küresel CDN uç noktalarından 10-20ms içinde yanıtlanır.

3. 033. Aşama: Asenkron İş Kuyrukları (150K - 500K DAU)

   • BullMQ / RabbitMQ ile İş Kuyruğu· Temel+

     50ms'den uzun süren hiçbir işlemi HTTP request-response döngüsünde senkron olarak çalıştırma.

     Bilmen gerekenler

     • Kullanıcı butona bastığında API işi kuyruğa ekler ve 18ms içinde '200 OK - İşleme Alındı' döner.
     • Arka plandaki bağımsız worker'lar işleri sırayla tüketir; worker çökse bile kuyruktaki veri kaybolmaz.

     Kaynaklar

     • BullMQ Dokümantasyonu (Redis Tabanlı Kuyruk)· Doküman
   • Retry Stratejisi & Dead Letter Queue (DLQ)· Temel+

     Üçüncü parti servis (SendGrid, Stripe vb.) geçici olarak çöktüğünde kullanıcıya hata verme; arka planda akıllıca yeniden dene.

     Bilmen gerekenler

     • Exponential Backoff ile bekleme süresini katlayarak yeniden dene (1s, 2s, 4s, 8s).
     • 5 denemede başarısız olan işleri Dead Letter Queue'ya alarak alarm üret ve geliştiricinin incelemesini sağla.

4. 044. Aşama: Domain Mikroservisleri & Event-Driven (500K+ DAU)

   • Domain Sınırlarına Göre Ayrım (DDD)· Temel+

     Bütün sistemi bir gecede bölmeye kalkışma; önce en bağımsız ve farklı ölçek ihtiyacı olan domainleri izole et (Auth, Payment, Notification).

     Bilmen gerekenler

     • Her mikroservisin kendi izole veritabanı olmalıdır (Database-per-Service); paylaşımlı veritabanı anti-pattern'dir.
     • 5+ bağımsız geliştirici ekibi birbirinin deploy sürecini beklemeden canlıya çıkmak zorundaysa servisleri ayır.

     Kaynaklar

     • Microservices Patterns (Chris Richardson)· Rehber
   • Apache Kafka ile Event Streaming· Temel+

     Servisler arası senkron HTTP çağrıları zincirleme çöküşe (cascading failure) yol açar; asenkron Event-Driven mimariye geç.

     Bilmen gerekenler

     • Sipariş oluştuğunda diğer servisleri doğrudan çağırma; 'OrderCreated' event'i fırlat, dinleyen servisler işini yapsın.
     • Sipariş verisini ve finansal kayıtları Event Sourcing / Outbox Pattern ile veritabanı yazımıyla atomik olarak eşitle.

     Kaynaklar

     • Apache Kafka Resmi Dokümantasyonu· Doküman
   • Dağıtık İzleme (Distributed Tracing & OpenTelemetry)· İyi olur+

     15 mikroservis arasında bir kullanıcının isteği 4 saniye sürdüğünde nerede takıldığını bulmanın tek yolu tekil Correlation ID ve OpenTelemetry'dir.

     Bilmen gerekenler

     • İstek kapıdan girdiği anda tekil bir Trace ID üretilir ve tüm servis çağrılarında HTTP başlığı olarak aktarılır.