Ön Yüz İçin Arka Yüz (BFF) ve Toplama Gecikme Yükü

Stack: SOFTWARE ARCHITECTURE STACK →Senior (L5)tradeoff

⚡ÖZET VE TEKNİK CEVAP

Ön Yüz İçin Arka Yüz (BFF) deseni; belirli istemci arayüzlerine (iOS, Web, IoT) özel uyarlanmış API toplama katmanları oluşturarak mobil pil tüketimini ve hücresel ağ turlarını azaltırken, alt mikroservisleri birleştirmenin getirdiği dağılma (fan-out) gecikme risklerini yönetir.

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma

Tek bir genel API hem masaüstü web'e, hem iOS'a hem de akıllı TV'lere hizmet verdiğinde kaçınılmaz ödünler doğar: Ya mobil uygulamalar gereksiz 500 KB veri indirir (aşırı çekme), ya da tek bir ekranı çizmek için 20 ardışık istek atar (yetersiz çekme). BFF, veri merkezinde alt servisleri paralel toplayıp tek optimize JSON dönen istemci odaklı bir adaptördür.

🎯2. Doğru Kullanım Senaryosu

Kapsam

Ön Yüz İçin Arka Yüz (BFF), tüm ön yüzlerin tek bir genel amaçlı API'yi kullanması yerine, belirli kullanıcı arayüzü deneyimleri (iOS, Web, SmartTV) için özel olarak geliştirilen ve sürdürülen bağımsız arka uç katmanıdır.

⚠️3. Prodüksiyon Arıza Modları

Kritik Risk

✓
Çekirdek iş mantığını BFF içine yazıp BFF'i saf bir adaptör yerine yeni bir monolite dönüştürmek. BFF içinde alt servis çağrılarını paralel yapmak yerine ardışık sırayla (`await A
✓
await B
✓
await C`) zincirlemek. iOS, Android, Web ve İş Ortakları için tek bir 'evrensel' ortak BFF yazıp başlangıçtaki genel API sıkı bağ problemine geri dönmek

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler

mobil uygulamanın hücresel ağda 40 ardışık REST çağrısı yapıp pili bitirmesi, yalnızca tek bir ekran için gereken alanlarla şişmiş genel API, en yavaş mikroservisin tüm BFF yanıt süresini kilitlediği toplama darboğazı

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler

✓
Tüm alt servis çağrılarına katı zaman sınırları koyun ve her biri için hazır zarif geri dönüş (fallback) şemaları tanımlayın. BFF katmanını tamamen durumsuz (stateless) tutun
✓
kalıcı durum için alt servislere veya dağıtık önbelleklere güvenin. BFF ile iç mikroservisler arasında yüksek hızlı gRPC/Protobuf kullanırken, dış mobil istemcilere optimize JSON/GraphQL sunun

⚖️6. Mimari Ödünleşimler (Trade-offs)

Ödünleşim

Yüksek gecikmeli hücresel ağlarda, istemci taraflı 20 istek yerine BFF üzerinden tek bir birleştirilmiş istek yapmak ekran yükleme süresini 4.5 saniyeden 400 milisaniyeye düşürür.

📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

Yüksek performanslı BFF mimarisi Paralel Dağıt-Topla ve Zarif Bozulma uzmanlığı gerektirir:

▸
Paralel Dağıt-Topla (Scatter-Gather): /home-feed uç noktasını oluşturmak için BFF; KullaniciServisi, KatalogServisi, OneriServisi ve SepetServisini yüksek hızlı gRPC üzerinden eşzamanlı olarak (Promise.allSettled() / Go errgroup) çağırır.
▸
En Zayıf Halka Gecikme Problemi: 3 servis 20 ms'de dönerken Öneri servisi 1.5 saniye sürerse tüm BFF yanıtı 1.5 saniyeye kilitlenir. BFF'ler her alt servise katı zaman sınırları (Öneri = 150 ms) koyarak bunu çözer. Süre aşılırsa tüm sayfayı patlatmak yerine zarifçe popüler ürünler listesini geri dönüş olarak sunar.
▸
Sahiplik Sınırı: Mobil BFF'in sahibi mobil ekiptir; böylece platform ekibini beklemeden yeni ekranlar için hızlı API şemaları geliştirebilirler.

İnteraktif Konsept Alıştırmaları

2 Alıştırma

Mobil uygulamalar için Ön Yüz İçin Arka Yüz (BFF) deseninin temel faydası nedir?

Birden fazla yavaş hücresel ağ çağrısını tek bir optimize istekle değiştirir; gereksiz alanları kırparak pil ve bant genişliği tasarrufu sağlar.

BFF toplayıcısındaki 'En Zayıf Halka' gecikme riski nedir ve nasıl çözülür?

En yavaş alt mikroservis toplam yanıt süresini belirler; her servise katı zaman sınırı koyup geciken servisler için zarif geri dönüş (fallback) verisi dönerek çözülür.