Hap Bilgi 17: Netflix Backend Mimarisi - Play Tuşuna Bastıktan Sonra Ne Olur?

Developer hap bilgi sever; 17. bölüm: Netflix Backend Mimarisi - Play Tuşuna Bastıktan Sonra Ne Olur?

Netflix’i açtığımızda ana sayfanın birkaç saniye içinde kişiselleştirilmesi, bir içeriğin arandığı anda bulunması ve play tuşuna basıldığında videonun gecikmeden başlaması bize oldukça basit görünür.

Oysa arka planda iki farklı sistem birlikte çalışır:

1. Kullanıcı, katalog, öneri, üyelik ve oynatma kararlarını yöneten backend servisleri
2. Video dosyalarını kullanıcıya en yakın noktadan taşıyan içerik dağıtım ağı

Netflix mimarisini anlamanın anahtarı tam olarak bu ayrımdır.

İlham aldığımız LinkedIn gönderisi; load balancer, API gateway, mikroservisler, cache, stream processing, arama, bildirim ve depolama katmanlarını yüksek seviyede bir araya getiriyor. Bu yazıda söz konusu paylaşımı yalnızca Türkçeye çevirmekle kalmayıp Netflix’in yayımladığı teknik kaynaklarla daha doğru bir sistem tasarımı okumasına dönüştüreceğiz.

Önemli not: Netflix’in mimarisi yaşayan ve sürekli değişen bir ekosistemdir. Buradaki şema, şirketin bütün sistemlerinin birebir ve eksiksiz envanteri değil; kamuya açık mühendislik kaynaklarından çıkarılmış yüksek seviyeli bir modeldir.

1. Önce Trafiği İkiye Ayıralım

Netflix’te play tuşuna basıldığında bütün trafik tek bir backend üzerinden akmaz.

Kontrol Trafiği
Client → Edge / Gateway → Domain Servisleri → Cache / Database

Video Trafiği
Client → Open Connect Appliance → Video Parçaları

Kontrol trafiği şu sorulara cevap verir:

• Kullanıcı kim?
• Aboneliği aktif mi?
• Hangi içerikleri görebilir?
• Ana sayfada hangi öneriler gösterilmeli?
• Seçilen içerik hangi kalitede oynatılabilir?
• Video hangi CDN sunucusundan alınmalı?

Video trafiği ise filmin veya dizinin kendisini taşır.

Bu ayrım kritik çünkü yüzlerce megabaytlık hatta gigabaytlık video verisini mikroservislerin ve API gateway’in içinden geçirmek hem pahalı hem de verimsiz olurdu.

Backend neyin oynatılacağına karar verir. CDN ise videoyu kullanıcıya taşır.

2. Client: Her Şeyin Başladığı Yer

Netflix yalnızca web tarayıcısında çalışan bir uygulama değildir.

İstemci tarafında;

• Web uygulaması
• Mobil uygulama
• Smart TV
• Oyun konsolu
• Set-top box
• Tablet

gibi çok farklı cihazlar bulunur.

Her cihazın işlem gücü, desteklediği codec, ekran çözünürlüğü ve bağlantı kalitesi farklıdır. Bu nedenle istemci yalnızca ekrana görüntü basmaz; cihaz yeteneklerini bildirir, bağlantı kalitesini ölçer ve uygun video kalitesini seçmeye yardımcı olur.

Netflix’in akıllı istemci yaklaşımı sayesinde video kalitesi bağlantı durumuna göre dinamik olarak değişebilir. Buna Adaptive Bitrate Streaming denir.

Bağlantı iyileşir  → Daha yüksek bitrate
Bağlantı zayıflar  → Daha düşük bitrate

Amaç her zaman en yüksek çözünürlüğü vermek değil, videonun takılmadan devam etmesini sağlamaktır.

3. Edge ve API Gateway: Sistemin Giriş Kapısı

İstemciden gelen API çağrıları önce trafik yönetimi ve gateway katmanından geçer.

Bu katmanın temel sorumlulukları şunlardır:

• İstekleri uygun servise yönlendirmek
• Kimlik doğrulama ve yetkilendirme kontrollerini uygulamak
• Rate limiting yapmak
• Request ve response dönüşümlerini yönetmek
• Cihaz türüne göre farklı veri sözleşmeleri sunmak
• Hatalı veya aşırı yük oluşturan trafiği sınırlandırmak

Kaynak LinkedIn gönderisinde bu bölüm AWS Elastic Load Balancer + API Gateway şeklinde gösteriliyor. Bu, genel bir sistem tasarımı şeması için anlaşılır bir sadeleştirmedir; ancak bunu Netflix’in bütün isteklerinde doğrudan Amazon API Gateway kullandığı şeklinde okumamak gerekir.

Netflix’in kamuya açık mühendislik yazılarında geçmişte Zuul gibi edge servisleri, daha güncel API katmanında ise Federated GraphQL Gateway yaklaşımı anlatılıyor.

GraphQL Federation ile istemci tek bir API yüzeyi görürken, şemanın farklı bölümleri ilgili domain ekipleri tarafından bağımsız olarak yönetilebilir.

Client
  ↓
GraphQL Gateway
  ├── Member Domain
  ├── Content Domain
  ├── Recommendation Domain
  └── Playback Domain

Gateway’in görevi iş kurallarının tamamını üstlenmek değil, istemci ile domain servisleri arasında kontrollü ve sade bir giriş noktası oluşturmaktır.

4. Mikroservisler: Küçük Servis Değil, Bağımsız Sorumluluk

Netflix’in backend mimarisi çok sayıda bağımsız servisten oluşur.

Örneğin yüksek seviyede şu domain’leri düşünebiliriz:

• Üyelik ve profil yönetimi
• İçerik kataloğu
• Arama
• Kişiselleştirme ve öneri
• Ödeme ve abonelik
• Oynatma yetkilendirmesi
• Cihaz yönetimi
• İzleme geçmişi
• Bildirimler

Mikroservis mimarisinin amacı yalnızca büyük bir uygulamayı küçük parçalara bölmek değildir.

Her servis;

• Kendi iş sorumluluğuna sahip olur.
• Bağımsız geliştirilebilir ve deploy edilebilir.
• İhtiyacına göre ayrı ölçeklenebilir.
• Hata durumunda diğer servislerden izole edilebilir.
• Kendi veri modelini ve uygun depolama teknolojisini seçebilir.

Ancak bu bağımsızlığın bir bedeli vardır: ağ hataları, veri tutarlılığı, servis keşfi, gözlemlenebilirlik ve operasyonel karmaşıklık.

Servis sayısı arttıkça bir servisin diğerinin ağ adresini sabit olarak bilmesi mümkün değildir. Service Discovery katmanı, çalışan servis instance’larını kaydeder ve isteklerin sağlıklı instance’lara yönlendirilmesini sağlar. Netflix bu problem için geçmişte Eureka gibi servis keşif çözümleri geliştirmiştir.

Mikroservis, dağıtık sistem problemlerini ortadan kaldırmaz; onları görünür ve yönetilebilir sınırlara taşır.

5. Cache: Her İstekte Veritabanına Gitmemek

Netflix gibi yüksek trafikli bir sistemde her isteğin doğrudan veritabanına ulaşması ciddi gecikme ve maliyet oluşturur.

Bu nedenle sık erişilen veriler bellek tabanlı cache katmanlarında tutulur:

• Kullanıcı oturum bilgileri
• Profil ve tercih verileri
• İçerik metadatası
• Hazır öneri listeleri
• Konfigürasyonlar
• Sık okunan servis cevapları

Netflix’in geliştirdiği EVCache, memcached tabanlı dağıtık bir cache çözümüdür. Düşük gecikme ve yüksek erişilebilirlik sağlamak için veriyi farklı AWS bölgeleri arasında çoğaltabilen bir yapı olarak kullanılır.

Request
  ↓
Cache kontrolü
  ├── Hit  → Veriyi hızlıca döndür
  └── Miss → Veri kaynağından oku → Cache’e yaz → Döndür

Burada iki farklı cache türünü karıştırmamak gerekir:

İkisi de cache’tir ama çözdükleri problem aynı değildir.

6. Event Streaming: Her Şeyi Senkron Yapmamak

Bir kullanıcı bir içeriği açtığında veya izlemeyi bıraktığında oluşan her verinin aynı HTTP isteği içinde işlenmesi gerekmez.

Örneğin şu olaylar asenkron olarak yayınlanabilir:

• İçerik görüntülendi
• Oynatma başladı
• Oynatma duraklatıldı
• İzleme tamamlandı
• Arama yapıldı
• Öneriye tıklandı
• Cihaz veya bağlantı hatası oluştu

Bu event’ler Kafka gibi bir mesajlaşma katmanı üzerinden farklı consumer’lara aktarılabilir.

Playback Event
      ↓
    Kafka
  ├── Analytics Consumer
  ├── Recommendation Consumer
  ├── Monitoring Consumer
  └── Data Lake Consumer

Netflix’in yayımladığı mühendislik çalışmalarında Kafka, Flink ve farklı stream processing platformlarının belirli veri akışlarında kullanıldığı görülüyor.

• Kafka: Olayları dayanıklı biçimde taşır.
• Flink: Gerçek zamanlı akışları işler ve dönüştürür.
• Spark: Büyük veri üzerinde batch processing ve analitik işlemleri yürütür.

Buradaki temel karar teknoloji isminden daha önemlidir:

Kullanıcının izleme deneyimi için zorunlu olmayan işler, ana istek yolundan çıkarılmalıdır.

Böylece analitik veya öneri sistemi geçici olarak yavaşlasa bile video oynatmaya devam edebilir.

7. Arama ve Bildirim: Ayrı Okuma Modelleri

Arama işlemi, ilişkisel veya operasyonel veritabanındaki tablolar üzerinde doğrudan sorgu çalıştırılarak ölçeklenmez.

İçerik katalogunda yapılan değişiklikler event olarak yayımlanabilir ve arama için optimize edilmiş ayrı bir index güncellenebilir.

Content Updated
      ↓
 Event Stream
      ↓
Search Consumer
      ↓
 Search Index

Aynı yaklaşım bildirim sisteminde de kullanılabilir. Yeni bir sezon eklendiğinde veya kullanıcıyı ilgilendiren bir içerik yayımlandığında bildirim servisi ilgili event’i tüketerek e-posta, push notification veya uygulama içi bildirim oluşturabilir.

Kaynak gönderide Elasticsearch arama teknolojisi olarak öneriliyor. Burada asıl çıkarım belirli bir ürüne bağlanmak değil, transactional veri modeli ile arama modelini birbirinden ayırmaktır.

8. Data Layer: Tek Veritabanı Her Probleme Yetmez

Netflix ölçeğindeki bir platformda bütün veriyi tek bir veritabanında tutmak gerçekçi değildir.

Farklı ihtiyaçlar farklı depolama modelleri gerektirir:

Bu yaklaşıma Polyglot Persistence denir: her veri türü için problemi en doğru çözen depolama teknolojisini kullanmak.

Ancak her yeni teknoloji aynı zamanda yeni bir operasyonel yük demektir. Bu nedenle doğru soru “Hangi veritabanı daha popüler?” değil, “Bu verinin erişim deseni ve tutarlılık ihtiyacı nedir?” olmalıdır.

9. Open Connect: Videoyu Kullanıcıya Yaklaştırmak

Netflix mimarisinin en önemli parçalarından biri kendi içerik dağıtım ağı olan Open Connect’tir.

Popüler video dosyaları, internet servis sağlayıcılarının ağına yerleştirilebilen Open Connect Appliance’larda önceden konumlandırılır. Böylece kullanıcı videoyu uzak bir AWS bölgesinden değil, ağ üzerinde kendisine çok daha yakın bir sunucudan alabilir.

Netflix Backend
  ↓ Oynatma kararı ve manifest
Client
  ↓ Video parçası isteği
Yakındaki Open Connect Appliance
  ↓
Video akışı

Bu tasarım;

• Başlangıç gecikmesini azaltır.
• İnternet omurgasındaki gereksiz trafiği düşürür.
• Daha yüksek görüntü kalitesi sağlar.
• Ana backend üzerindeki bant genişliği yükünü azaltır.
• Bölgesel arızalara karşı daha dayanıklı bir dağıtım modeli oluşturur.

Kısacası Netflix’in ölçeklenmesini sağlayan yalnızca mikroservis mimarisi değildir. Video içeriğinin kullanıcıya fiziksel olarak yaklaştırılması da en az backend kadar önemlidir.

10. Resilience: Hata Olmayacağını Varsaymamak

Dağıtık bir sistemde servisler yavaşlar, makineler kapanır, ağ bağlantıları kopar ve bağımlılıklar cevap vermez.

Netflix’in yaklaşımı bu hataları istisna olarak görmek değil, sistemin doğal bir parçası kabul etmektir.

Başlıca dayanıklılık mekanizmaları şunlardır:

• Timeout
• Sınırlı retry ve exponential backoff
• Circuit breaker
• Fallback response
• Load shedding
• Bölgesel aktif-aktif çalışma
• Failure injection ve chaos testing
• Merkezi log, metrik ve distributed tracing

Örneğin öneri servisi cevap veremediğinde ana sayfanın tamamen çökmesi yerine daha önce hazırlanmış popüler içerik listesi gösterilebilir.

Recommendation Service
  ├── Başarılı → Kişiselleştirilmiş içerik
  └── Hatalı   → Genel popüler içerik listesi

Bu, sistemin kusursuz olduğu anlamına gelmez. Hata anında kullanıcı deneyiminin kontrollü biçimde düşürülmesi anlamına gelir.

Dayanıklı sistem, hiç hata vermeyen sistem değil; hata verdiğinde ne yapacağını bilen sistemdir.

11. Play Tuşuna Basıldığında Ne Olur?

Artık bütün parçaları tek bir akışta birleştirebiliriz:

1. İstemci kullanıcı ve cihaz bilgileriyle backend’e istek gönderir.
2. Gateway isteği ilgili domain servislerine yönlendirir.
3. Üyelik, profil, içerik yetkisi ve cihaz uyumluluğu kontrol edilir.
4. Cache katmanı sık erişilen verileri düşük gecikmeyle döndürür.
5. Playback servisi uygun video manifestini ve CDN konumunu belirler.
6. İstemci video parçalarını yakındaki Open Connect Appliance’dan almaya başlar.
7. Bağlantı kalitesine göre bitrate dinamik olarak değiştirilir.
8. İzleme event’leri asenkron olarak veri platformuna gönderilir.
9. Analitik ve öneri sistemleri bu event’leri daha sonra işler.

Play
  ↓
Yetki + Cihaz + İçerik Kontrolü
  ↓
Playback Manifest
  ↓
Open Connect Seçimi
  ↓
Video Parçalarının İndirilmesi
  ↓
Asenkron İzleme Event’leri

Kullanıcı için tek bir buton olan play, backend tarafında senkron ve asenkron birçok kararın koordinasyonudur.

Gönderinin Türkçe Mimari Özeti

Sık Yapılan Yanlışlar

❌ “Video, API Gateway ve mikroservislerin içinden kullanıcıya akar.”
✅ Backend oynatma kararını verir; video parçaları Open Connect üzerinden taşınır.

❌ “Mikroservise geçince sistem otomatik olarak ölçeklenir.”
✅ Bağımsız ölçekleme avantajı; observability, otomasyon ve doğru domain sınırlarıyla birlikte anlam kazanır.

❌ “Application cache ile CDN cache aynı şeydir.”
✅ Biri servis verisini hızlandırır, diğeri büyük içerik dosyalarını kullanıcıya yaklaştırır.

❌ “Bütün event’ler gerçek zamanlı işlenmelidir.”
✅ Yalnızca iş ihtiyacı gerçek zamanlıysa stream processing kullanılmalıdır; birçok analitik iş batch olarak yürütülebilir.

❌ “Chaos engineering production’da rastgele servis kapatmaktır.”
✅ Kontrollü hipotezler, ölçülebilir etki alanı ve güvenlik sınırlarıyla sistem dayanıklılığını doğrulama disiplinidir.

❌ “Netflix bu teknolojiyi kullanıyorsa biz de kullanmalıyız.”
✅ Mimariyi teknoloji isimleriyle değil, çözülen problemler ve sistemin gerçek ölçeğiyle değerlendirmek gerekir.

Özet

Netflix’in backend mimarisi tek bir teknolojiyle açıklanamaz.

Sistemin asıl gücü bu parçaların tek tek var olmasından değil, doğru sorumluluklarla birbirinden ayrılıp birlikte çalışmasından gelir.

Hap Bilgi

“Netflix ölçeğini yalnızca mikroservislerden değil; karar trafiği ile video trafiğini ayıran, veriyi doğru yerde işleyen ve hatayı sistemin doğal bir parçası kabul eden mimarisinden alır.”

Play tuşunun arkasındaki gerçek mühendislik tam olarak budur.

Her zaman olduğu gibi kaynaklara mutlaka göz atılmasını tavsiye ediyorum. ⬇️

• Rocky Bhatia — Netflix Backend Architecture
• Netflix TechBlog — How Netflix Scales its API with GraphQL Federation, Part 1
• Netflix TechBlog — How Netflix Scales its API with GraphQL Federation, Part 2
• Netflix Open Connect — Program Overview
• Netflix Open Connect — Appliances
• Netflix TechBlog — Caching for a Global Netflix
• Netflix TechBlog — Keystone Real-time Stream Processing Platform
• Netflix TechBlog — Streaming SQL in Data Mesh
• Netflix TechBlog — FIT: Failure Injection Testing
• AWS — Netflix Case Study