Mobil ve Web Urunlerinde Olceklenebilirlik

Ölçeklenebilirlik, trafik ve kullanıcı sayısı arttığında ürününüzün nasıl davrandığını belirleyen mimari disiplindir. 100 kullanıcıda iyi çalışan bir sistem, 100.000'de çöker — bu sessiz geçişi öngörmek teknik liderin işidir. Bu yazıda mobil ve web ürünlerde uzun vadede mimariyi stabil tutan dört temel prensip var.

Altyapı Katmanı: Elastik Baştan Tasarlamak

Ölçeklenebilirliğin ilk prensibi "baştan dağıtık değil ama dağıtılabilir" kurmaktır. Monolit bir backend ile başlamak doğru karardır — ancak veritabanı, cache ve dosya depolama ayrı servisler olarak konumlandırılmalı. Bu, 2. yılda servis ayrıştırma ihtiyacı doğduğunda geri dönüşü kolaylaştırır.

Pratik altyapı kararları:

• Compute: Heroku/Railway gibi PaaS çözümleri MVP'de yeterli, ama erken yük için AWS ECS/GCP Cloud Run'a geçiş yolu hazır olmalı
• Veritabanı: PostgreSQL primary + read replica yapısı 50.000+ kullanıcıdan önce hazır
• Object storage: S3/GCS'ye yüklenen dosyalar, uygulama sunucusundan bağımsız olmalı
• CDN: Cloudflare/CloudFront statik varlıklar için varsayılan

Cache Stratejileri

Cache, performans ve maliyet optimizasyonunun en yüksek ROI'li aracıdır ama yanlış yönetildiğinde en zor debug edilen sorunların kaynağıdır. Üç katmanlı cache yaklaşımı pratik:

1. CDN cache: Statik varlıklar ve public API yanıtları 5-60 dk
2. Application cache (Redis): Kullanıcı oturumları, ağır DB query sonuçları, rate limit counter
3. Client cache: React Query / Flutter cached_network_image ile istemci tarafında

Cache invalidation için üç strateji karışık kullanılır: TTL (zaman bazlı), event-based (DB değiştiğinde bildirim), ve manual (admin flush). Bir kural: cache'in çalıştığından emin değilseniz, cache yoktur. Metric ekleyin — cache hit/miss oranını ölçün.

Servis Ayrıştırma: Ne Zaman, Nereden?

Microservice'e erken geçmek startup'ların en sık yaptığı hatadır. Ayrıştırma kararı teknik değil, organizasyonel ihtiyaçla gelir — iki ekip aynı kod tabanında aynı anda çalışırken çakıştığında. Pratik eşikler:

• 10+ developer aynı monolit repoda: Deploy kuyruğu ve merge çakışmaları ayrıştırmayı zorunlu kılar
• Farklı SLA gereksinimleri: Ödeme servisi 99.99% isterken, notification 99.5% ile idare edebiliyorsa ayırın
• Scaling profili ayrışıyor: Resim işleme CPU'ya aç, chat memory'ye aç — ayrı servisler ayrı altyapı profili gerektirir

İlk ayrıştırma kararı genellikle "notification + email + scheduler" gibi yan akışları ayırmaktır. Ana ürünü ikiye bölmekten önce bu kenar servisleri bağımsızlaştırın.

Gözlemlenebilirlik: Körlüğü Kaldırmak

Ölçeklenebilirliğin 3. prensibi, neyin yavaşladığını bilmektir. Gözlemlenebilirlik üç ayakta durur:

• Logs: Yapılandırılmış (JSON) log'lar tek yere — Datadog, Grafana Loki, veya self-hosted ELK
• Metrics: Request count, latency (p50/p95/p99), error rate. Prometheus + Grafana veya bulut-native alternatifleri
• Tracing: Dağıtık bir istek birden fazla servisten geçtiğinde, hangi adımın yavaş olduğunu gösteren distributed tracing (OpenTelemetry)

İlk aşamada Sentry + basit bir Grafana dashboard'u yeterli. Ancak 50.000 kullanıcı eşiğinde APM (Application Performance Monitoring) yatırımı şart hale gelir. New Relic, Datadog APM veya Grafana Tempo alternatifleri.

Mobil Tarafında Ölçeklenebilirlik

Backend kadar konuşulmayan ama kritik bir konu: mobil uygulamada ölçeklenebilirlik. Flutter veya React Native kod tabanının 3. yılda korunabilir olması için:

• Feature-first klasör yapısı: screens/ yerine features/auth/, features/chat/ modüler organizasyon
• Design system: Component kütüphanesi, yeni ekran yapımını 4-5 saatten 1 saate indirir
• Offline-first mimari: Redux/Riverpod persistence + sync. Kullanıcı internetsiz de kullanabilmeli
• Performance budget: App size, cold start time, FPS metriklerine CI'da limit koyun

Ölçeklenme Pratik Senaryosu

Bir B2C mobile + web SaaS örneği: 500 kullanıcıdan 50.000'e çıkan 18 aylık büyüme. Kritik dönüm noktaları:

• 2.000 kullanıcı: Redis cache + queue sistemi (BullMQ) eklendi, email gönderim senkronluktan async'e taşındı
• 10.000 kullanıcı: Read replica + image CDN, mobil uygulamada offline cache
• 30.000 kullanıcı: Notification + search servisleri ayrı microservice olarak ayrıldı
• 50.000 kullanıcı: APM yatırımı, performance budget CI kontrolü, database sharding planlaması