Bir müşteri için backend tasarlarken “global users var, multi-region yapalım” dedim. US-East, EU-West, Asia-Pacific. Latency düşsün, resilience artsın, modern mimari. 3 ay sonra ekip devops’a boğulmuş durumdaydı, maliyet 4 katına çıkmıştı ve kullanıcı deneyimi hiç iyileşmemişti. Çünkü gerçek kullanıcı dağılımı %85 Türkiye’ydi.
Bu deneyim bana şunu öğretti: multi-region deployment pek çok ürün için gerçek bir ihtiyaç değil, mühendislik gösterişi oluyor.
Ne zaman gerçekten gerekli
Multi-region mimariyi gerekli kılan net 4 senaryo var:
Global kullanıcı dağılımı, ölçülebilir latency baskısı. Kullanıcılarınız gerçekten farklı kıtalarda ve p95 latency 300ms üzerine çıkıyor. 200ms altındaki bir uygulamada region ekleyerek kazanacağınız 40-50ms çoğu kullanıcı için hissedilmez.
Regulatory requirement. GDPR sonrası AB’de data residency zorunluluğu, Rusya’nın veri lokalizasyon yasası, Çin’in kendi regülasyonları. Kullanıcının verisinin fiziksel olarak belirli bir coğrafyada tutulması zorunluysa multi-region kaçınılmaz.
Regional failover gereksinimi. Bir AWS region tamamen düştüğünde ürününüzün devam etmesi gerekiyorsa (finansal servisler, acil durum ürünleri, SLA’lı B2B) multi-region disaster recovery şart.
Çok yüksek throughput. Tek bir region’un network egress kapasitesinin sınırına dayanıyorsanız. Bu çoğu ürün için geçerli değil.
Bunlardan biri bile güçlü bir şekilde karşılığını vermiyorsa multi-region yapmayın.
Karmaşıklık faturası
İkinci region açtığınız anda ortaya çıkan problemler:
Data replication. RDS read replica’yı başka region’a açmak kolay, kolay olmayan write replikasyonu. Cross-region write senkron olursa latency patlar, asenkron olursa eventual consistency sorunları başlar. Kullanıcı login olduğu region’da oluşturduğu kaydı diğer region’da göremez, destek ekibi kriz yaşar.
Session yönetimi. Kullanıcı EU-West’te login olmuş, sonra US-East’e düşmüş. Session store merkezi mi, replike mi? Her iki seçenek de karmaşıklık getiriyor.
Deploy koordinasyonu. Her release’i farklı region’larda nasıl rollout edeceksiniz? Canary deploy multi-region’da nasıl çalışır? Bir region’da hata yakalayıp diğerinde yayına gitmek rollback matematiğini karmaşıklaştırır.
Maliyet. Cross-region data transfer AWS’de en yüksek ücretli kalem. Replikasyon trafiği ayda binlerce dolar fatura yaratabilir. İki region demek iki katı infra demek, ama team’iniz iki katına çıkmıyor.
Observability. Logları, metrikleri, trace’leri nasıl birleştireceksiniz? Region’lar arası request zincirini takip etmek için dağıtık tracing kurulumu ekstra iş.
Alternatif: edge + tek region
Çoğu ürün için optimum mimari şu: core backend tek region’da, static asset’ler ve public API cache’lenen response’lar için CDN edge. Cloudflare, Fastly, CloudFront edge compute ile public API’nin read-heavy kısmını çözebilirsiniz. Write traffic tek region’a gider, user latency read’lerde iyileşir.
Türkiye’den servis veren çoğu ürün için EU-Central (Frankfurt) region + global CDN yeterli. Frankfurt’tan Türkiye’ye latency 35-45ms civarı, hissedilmeyecek kadar iyi.
Karar matrisim
Bir ürüne multi-region eklemeden önce şunlara bakıyorum:
- Kullanıcıların gerçek coğrafi dağılımı (analytics’e bak, ekip tahminine değil)
- Şu anki p95 latency’nin region’lar arası dağılımı
- Regulatory gereksinim var mı
- SLA taahhüdü kaç 9 gerektiriyor
- Yıllık ek maliyetin ürün revenue’süne oranı
Bu 5 soruyu cevaplamadan multi-region tartışmasına girmiyorum.
Başlangıç noktası: iyi bir tek region
Multi-region öncesi yapılacak çok şey var: caching katmanı, DB query optimizasyonu, async job queue, read replica, CDN. Bunların her biri multi-region’a kıyasla çok daha düşük karmaşıklık ile latency ve throughput iyileştirmesi sağlar.
Bir ürün 10-20 milyon kullanıcıya ulaşmadan multi-region konuşmak genelde erken. Önce ürünü büyütün, sonra ölçek probleminin tam şeklini görün, sonra ona göre mimari seçin.
Erken multi-region kararları sonradan geri almak çok pahalı. Bir başlatınca iki region’un ikisini de devre dışı bırakmak yıllar sürer. Başlangıçta iyi bir tek region ile başlayıp kritik eşiğe geldiğinizde scale out etmek daha sürdürülebilir yaklaşım.