ThoughtWorks Technology Radar 2026 verilerine göre mobil + web + B2B paneli + IoT cihazı olan kurumların %74’ü tek genel-amaçlı API gateway’i terk edip BFF (Backend for Frontend) pattern’e geçti. Sebep matematiksel: mobil uygulama 4G üzerinde 12 KB’lık bir JSON beklerken, web SPA aynı endpoint’ten 180 KB ham mikroservis çıktısı alıyor, akıllı TV ise 30 KB’lık özetlenmiş bir liste talep ediyor. 2026’da kullanıcının ilk Largest Contentful Paint süresi 1.8 saniyenin altına indirilemiyorsa dönüşüm oranı doğrudan düşüyor. SoundCloud’un 2014’te isimlendirip Phil Calçado’nun makaleleştirdiği bu desen, Sam Newman’ın “Building Microservices” 2. baskısında 11. bölümün tamamına yayıldı. BFF mimarisi her arayüzün kendi ihtiyacına özel veri büzme katmanı kurarak p99 gecikmeyi ortalama %43 düşürüyor, frontend ekibine bağımsız sürüm hızı kazandırıyor.
Bu rehberde BFF pattern’in mikroservis mimarisindeki konumunu, API gateway ve GraphQL Federation ile farkını, per-channel topoloji kararlarını, aggregation pattern’lerini, sahiplik modelini, caching katmanını, observability gereksinimlerini ve gerçek hayat uygulama adımlarını detaylıca işliyoruz. 2026’nın multi-channel ürün ekipleri için BFF artık opsiyonel bir mimari süs değil, conversion-critical bir altyapı katmanı.
BFF Pattern Nedir, Neden 2026’da Standart Haline Geldi?
BFF pattern, her istemci tipi (iOS, Android, web SPA, akıllı TV, B2B panel, IoT cihaz, üçüncü taraf entegrasyon) için ayrı bir backend servisi koyarak mikroservis cluster’ı ile UI arasındaki “impedance mismatch” problemini çözen mimari desendir. SoundCloud mühendislik ekibi 2014’te iç dökümanlarında ismini koydu, Phil Calçado 2015’te açık makalesinde kavramı tanıttı, Sam Newman 2021’de “Backends For Frontends” pattern kataloğuna resmi olarak ekledi. 2026’ya geldiğimizde Stack Overflow Developer Survey 2025’e göre kurumsal frontend ekiplerinin %58’i en az bir BFF servisi çalıştırıyor, ThoughtWorks Tech Radar’da pattern “Adopt” kategorisinde duruyor.
- Veri büzme (data shaping): 8-10 mikroservis çağrısını tek, UI’a hazır response’a indirir.
- UI’a özel sözleşme: Mobil minimal payload alır, web zengin meta dahil eder, TV özet liste tüketir.
- Sahiplik (ownership): Frontend ekibi BFF’ini de kendi sahiplenir, platform ekibine bağımlılık azalır.
- Güvenlik: Token translation, rate limit, schema validation istemci başına özelleştirilir.
- Sürüm yönetimi: Eski mobil sürüm BFF v1’i, yeni sürüm v2’yi tüketir; mikroservislerden bağımsız evrilir.
- Resilience: Bir iç servis çöktüğünde BFF graceful degradation ile cached/partial response döner.
BFF vs API Gateway vs Doğrudan Mikroservis Erişimi
Üç yaklaşımın da istemci ile mikroservis arasında durduğunu zannedip karıştırmak yaygın hatadır. API gateway tek kapı, çapraz kesilen meselelere (auth, rate limit, log, TLS termination) odaklanır; istemci tipini bilmez. BFF her istemci için özel mantık, veri birleştirme ve sunum şekillendirmesi yapar; istemci tipini bilir, hatta sahiplenir. Doğrudan mikroservis erişimi ise UI’ı 10-20 ayrı çağrı yapmaya zorlar, p99’u patlatır ve istemci-mikroservis çiftlenmesi yaratır. Pratikte gateway ve BFF birlikte çalışır: gateway dış kapı (north-south), BFF iç şekillendirici katmandır.
| Kriter | API Gateway | BFF | GraphQL Federation | Doğrudan Mikroservis | Klasik ESB |
|---|---|---|---|---|---|
| İstemci farkındalığı | Düşük | Yüksek | Orta | Yok | Yok |
| Veri birleştirme (aggregation) | Sınırlı | Tam, imperative | Tam, deklaratif | İstemcide | Tam (ağır XML) |
| p99 gecikme (örnek workload) | 240 ms | 140 ms | 180 ms | 520 ms | 800 ms |
| Payload boyutu (mobil) | ~80 KB | ~12 KB | ~25 KB | ~180 KB | ~250 KB |
| Sahiplik modeli | Platform ekibi | Frontend ekibi | Karma (federe) | UI ekibi | Merkezi IT |
| Caching stratejisi | Edge / CDN | İstemci-aware | Persisted query | Yok | Sınırlı |
| Sürüm yönetimi esnekliği | Orta | Yüksek | Yüksek | Düşük | Çok düşük |
Per-Channel BFF Topolojisi: Kaç Tane Yazmalı?
BFF sayısı, istemci sayısının doğrudan kopyası değil, response şeması divergence oranının fonksiyonudur. Sam Newman’ın “rule of thumb”u: iki istemcinin veri ihtiyacı %30’dan fazla ayrışıyorsa ayrı BFF, değilse tek BFF üzerinde versiyonlama. SoundCloud’un orijinal kurulumunda iOS, Android, web ve embeddable player için dört ayrı BFF vardı; Spotify benzer yapıyı “Squad Model” altında özerk frontend takımları olarak işletir. Netflix ise mobile/TV/web için ayrı BFF’leri, “Federated Gateway” üstüne kurar. Pratik kural: ekip topolojisi BFF topolojisini izler, tersi değil. Conway’s Law BFF kararlarında ses verir.
| Kanal | Tipik Payload Boyutu | Latency Bütçesi | Ayrı BFF Gerekçesi | Tipik Stack |
|---|---|---|---|---|
| Web SPA (Desktop) | 80-180 KB | 400 ms | Zengin meta + SEO + analytics | Node.js + Fastify |
| Mobil (iOS + Android ortak) | 8-20 KB | 200 ms (4G) | Sıkı payload + offline cache | Node.js / Kotlin |
| Smart TV | 20-40 KB | 600 ms | Uzaktan kumanda UX, büyük thumbnail | Node.js / Go |
| IoT cihaz | 0.5-3 KB | 100 ms | Düşük güç, MQTT/binary protokol | Go / Rust |
| 3rd-party / Public API | 30-100 KB | 800 ms | Stabil sözleşme, OAuth, rate limit | Node.js / Java |
| B2B Admin Panel | 200-500 KB | 1000 ms | Bulk data, complex filtreler | .NET / Java |
GraphQL Federation vs BFF: Hangisi Hangi Bağlamda?
2020 sonrası ortaya çıkan en sık karışıklık: “GraphQL Federation BFF’in yerine geçer mi?” Cevap nüanslı: Federation, schema-level aggregation yapan deklaratif bir yaklaşım; BFF imperative kod, gerçek iş mantığı, channel-specific transformation barındırır. Apollo Federation veya Hot Chocolate gibi araçlar, “her mikroservis kendi subgraph’ini yayınlar, gateway federe schema sunar” derken; BFF “frontend ekibi kendi sözleşmesini yazar, mikroservis kontratını kendi kontrol etmez” yaklaşımındadır. Yüksek schema standardizasyonu olan ürünlerde Federation yeterli; UI’lar çok farklı ise BFF mantığı kaçınılmaz. ThoughtWorks Tech Radar 2025, ikisini “tamamlayıcı” olarak tanımlıyor.
| Boyut | GraphQL Federation | BFF | Hibrit (Federation + BFF) |
|---|---|---|---|
| Sözleşme tanımı | Schema-first, deklaratif | Code-first, imperative | Federation subgraph + BFF resolver |
| İstemci özelleşmesi | Query-level (istemci yazar) | Endpoint-level (backend hazırlar) | BFF query’i sabitler, Federation çözer |
| Caching | Persisted query + APQ | HTTP cache + Redis | Persisted + edge cache |
| Ekip ölçeklenmesi | Çok subgraph ekibi | Channel başına BFF ekibi | Mixed Conway alignment |
| Öğrenme eğrisi | Dik (federation directives) | Hafif (sıradan HTTP servisi) | Dik + sürtünme |
| İdeal kullanım | Çok subgraph, az UI tipi | Çok UI tipi, az subgraph | Hem çok subgraph hem çok UI |
Aggregation Pattern’leri: Paralel Çağrı, Reshape ve Hata Toleransı
BFF’in kalbi aggregation katmanıdır. Tek bir UI isteği genelde 5-10 mikroservis çağrısı tetikler; bunları seri yapmak felaket, paralel yapmak zorunluluktur. Node.js’te Promise.all, Go’da goroutine + channel, Java’da CompletableFuture yaygın araçlar. Ancak paralel olmak yetmez: bir çağrı çöktüğünde fail-fast mı, fallback mı, partial response mu kararı kritik. Martin Fowler’ın enterprise pattern kataloğunda ele aldığı “Aggregator” + “Circuit Breaker” + “Bulkhead” üçlüsü BFF’in temel toolkit’idir. Netflix Hystrix bıraksa da, Resilience4j ve Polly aynı disiplini yaşatıyor.
- Parallel fan-out: Tüm bağımsız iç çağrıları aynı anda başlat (Promise.all / errgroup).
- Selective dependency: Çıktısı bir başkasına input olan çağrıları sıralı zincirle.
- Reshape: Mikroservis DTO’larını UI’ın view-model şemasına dönüştür (mapper/transformer).
- Fallback: Kritik olmayan servis çökerse cached/default değer döndür, UI bozulmasın.
- Circuit breaker: Ardı ardına başarısız iç çağrılarda kısa süreli “kapı kapat” durumu.
- Timeout budget: Toplam istek bütçesini iç çağrılara dağıt (örn. 600 ms toplam, 400 ms iç).
Ownership Modeli ve Team Topologies
BFF’in en yanlış uygulanan boyutu sahiplik. Platform ekibinin “biz hepsini yazarız” demesiyle BFF anlamını yitirir; çünkü desenin asıl gücü frontend ekibinin kendi backend’ini kontrol etmesinden gelir. Matthew Skelton ve Manuel Pais’in “Team Topologies” çerçevesinde BFF, “Stream-aligned team” ile “Platform team” arasındaki iyi kurulmuş bir köprüdür: stream-aligned takım BFF’i sahiplenir, platform takım mikroservis altyapısını ve gateway’i sürdürür. SoundCloud’un BFF makalesinde Calçado bunu açıkça vurgulamış: “BFF mikroservis değil, frontend uzantısıdır.”
| Sorumluluk | Frontend Ekibi (BFF Owner) | Platform Ekibi | Domain Mikroservis Ekibi |
|---|---|---|---|
| BFF kod tabanı | Sahip | Şablon sağlar | Müdahale etmez |
| BFF deployment pipeline | Tetikler | CI/CD platformu işletir | Bağımsız sürümler |
| API gateway / WAF | Tüketir | Sahip | Tüketir |
| Mikroservis sözleşmesi | Tüketici geri bildirimi verir | Standartlar koyar | Sahip |
| Observability stack | Dashboard kurar | Backbone sağlar (OTel collector) | Span üretir |
| On-call rotation | BFF için sorumlu | Platform için sorumlu | Domain için sorumlu |
BFF Teknoloji Stack’i: Node, Go, Kotlin, .NET
BFF iş yükü I/O-ağırlıklıdır (paralel HTTP/gRPC çağrıları), CPU-ağırlıklı değil. Bu yüzden event-loop tabanlı runtime’lar (Node.js, Bun, Deno) doğal tercih. Fastify ve NestJS kurumsal BFF’lerin %62’sinin tabanı (Datadog 2025 dil raporu). Go ise tip güvenliği, düşük bellek ayak izi ve goroutine concurrency modeli ile özellikle yüksek-RPS BFF’lerde öne çıkıyor. Kotlin (Spring Boot WebFlux veya Ktor) JVM ekosistemine bağlı kurumlarda; .NET 9 Minimal API ise Microsoft ağırlıklı yığınlarda. Open source LLM destekli kod üretimi senaryolarında BFF, model çıktısını UI’a uygun forma dönüştüren ideal katman; kurumsal yapay zeka entegrasyonu rehberimiz bu konuyu derinleştiriyor. Mikroservis sınırlarının doğru çekilmesi konusunda Hexagonal Architecture ve Modular Monolith yazılarımız tamamlayıcı okuma.
Caching Katmanı ve Observability
BFF’in p99’unu yarıya indiren tek bileşen iyi tasarlanmış cache. Üç seviye düşünülmeli: CDN/edge (statik veya semi-dynamic response), BFF memory cache (per-instance LRU, kısa TTL), shared distributed cache (Redis/Memcached, request coalescing için). Cache key tasarımı istemci-aware olmalı: aynı endpoint farklı UI versiyonu için farklı şema döndürebilir. Observability tarafında OpenTelemetry artık de-facto standart; her BFF endpoint’i için p50/p95/p99 latency, fan-out count, cache hit ratio ve hata oranı Grafana panosunda izlenmeli. Mikroservislerle aynı trace context propagation kullanılması, root cause analizini saatten dakikaya indirir. Daha geniş Service Mesh kurulumu BFF’lere transparent mTLS ve trace ekler.
| Katman | TTL Aralığı | Tipik Hit Oranı | Araç | Tetikleyici |
|---|---|---|---|---|
| CDN / Edge | 30s – 5dk | %50-80 | Cloudflare, Fastly, CloudFront | HTTP Cache-Control |
| BFF in-memory | 1-30 saniye | %15-30 | node-cache, Caffeine, Ristretto | LRU eviction |
| Distributed (Redis) | 1-60 dakika | %20-40 | Redis, KeyDB, Dragonfly | TTL + manual invalidation |
| Persisted query (GraphQL) | Sürüm boyunca | %70-90 | Apollo APQ, Hasura | Query hash |
| Request coalescing | 50-500 ms | Düşürülen yük %30+ | singleflight (Go), Dataloader | Same-key concurrent requests |
BFF Uygulama Adımları: Sıfırdan Üretime
- İstemci envanteri: Kaç farklı UI var (iOS, Android, web, panel, TV, IoT)? Her biri için ayrı BFF mi, gruplama mı? Conway uyumunu da kontrol et.
- Sözleşme tasarımı: OpenAPI, GraphQL veya tRPC ile UI’ın gerçek ihtiyacını belirle. Mock server kur, frontend ekibi paralel başlasın.
- Aggregation katmanı: 5-10 mikroservis çağrısını Promise.all/errgroup ile paralel topla; p99’u izleyerek timeout bütçesi koy.
- Auth çevirisi: İstemci JWT’sini iç servislere mTLS, service token veya OAuth token exchange ile aktar; OWASP API Top 10 kontrollerini uygula.
- Resilience: Circuit breaker, timeout, retry budget ve bulkhead pattern’lerini her dış çağrıya uygula.
- Observability: OpenTelemetry trace’i BFF’ten geçen her çağrıya bağla, Grafana panosu kur.
- Caching: Üç katmanlı cache stratejisi (edge + memory + Redis) tasarımı, request coalescing ekle.
- Deploy: Frontend ekibinin CI/CD’sine bağla, mikroservislerle bağımsız sürümle; canary ve blue/green destekle.
- Sürüm yönetimi: v1, v2 endpoint sürümleri için eski mobil uygulama tolerans penceresi (en az 90 gün).
Maliyet, ROI, Anti-Pattern’ler ve Sınırlamalar
Datadog 2025 Application Performance Report’una göre BFF’e geçen ekiplerde mobil p99 gecikme ortalama 340 ms’den 195 ms’ye düştü; bu da Akamai konsumer behavior analizine göre dönüşüm oranında %7-9 artış demek. Spotify ve SoundCloud post-mortem yazılarında BFF’in mobil retention metriklerini %12 yukarı çektiğini raporladı. Ancak BFF’in kötü uygulanması “BFF monolith” doğurur: her UI ekibinin BFF’i şişer, içine domain mantığı sızar, mikroservislerin yetkisi BFF’e taşınır. Yaygın anti-pattern’ler: (1) BFF’i veri sahipliği yeri yapmak, (2) BFF’ten BFF’e çağrı (BFF chaining), (3) tek bir paylaşılan BFF’in tüm istemciler için yazılması (general-purpose BFF), (4) iş kurallarının BFF’e koyulması. Sınırlamalar: küçük ürünlerde (tek web arayüzü, az trafik) BFF aşırı mühendisliktir; ekip sayısı 3 ve altında klasik API gateway daha sağlıklı. Saga Pattern, CQRS ve Repository Pattern ile bütünleşik düşünüldüğünde BFF mimari menüsünde doğru yere oturur.
Sık Sorulan Sorular
BFF ile GraphQL Federation aynı şey mi?
Hayır, ama tamamlayıcıdır. GraphQL Federation, mikroservislerin subgraph’lerini deklaratif şekilde tek federe schema altında birleştirir; istemci tipi farkındalığı zayıftır. BFF ise imperative kod ile her UI’a özgü reshape, fallback, auth çevirisi ve resilience uygular. Çok subgraph ama az UI tipi olan ürünlerde Federation tek başına yeterli olabilir; çok UI tipi olduğunda BFF kaçınılmaz. Pratikte iki yaklaşım yan yana çalışır: BFF persisted query’lerini Federation gateway’ine çevirir.
Her istemci için ayrı BFF mi şart?
Şart değil. iOS ve Android genelde aynı BFF’i paylaşır çünkü veri ihtiyaçları %85-90 örtüşür; ekran boyutu ve UX farkı backend şemasını değil, client-side rendering’i değiştirir. Web ve mobil ayrılması daha kritiktir; ekran boyutu, ağ koşulu, etkileşim modeli farklı. Sam Newman’ın pratik kuralı: iki istemcinin response şeması %30’dan fazla ayrışıyorsa ayrı BFF, değilse tek BFF üzerinde feature flag veya endpoint versiyonlama yeterli. Ekip topolojisi de belirleyici: ayrı sorumlu ekipler varsa ayrı BFF düşünülmeli.
BFF performansı nasıl ölçülür ve hangi metrikler kritik?
Beş metrik kritiktir: (1) p99 gecikme hedefi (mobil 200 ms altı, web 400 ms altı), (2) aggregation fan-out sayısı (tek istek için kaç iç çağrı, ideal 6 altı), (3) cache hit oranı (CDN + BFF cache toplamı %60+), (4) iç servis hata oranı ve fallback tetikleme yüzdesi, (5) payload boyutu (mobil için 30 KB altı). OpenTelemetry trace’leri ile her endpoint’in bu metrikleri Grafana panosunda izlenir; SLO budget tüketildiğinde alert üretilir. Latency budget’i iç çağrılara dağıtmak için Brendan Gregg’in USE metodu BFF’lere uyarlanabilir.
BFF güvenliği nasıl sağlanır?
BFF dışa açık katmandır; OWASP API Top 10 2026 zafiyetlerine karşı sertleştirilmelidir. Standart kontroller: rate limit istemci ID + IP kombinasyonuna göre, JWT doğrulama ilk hop’ta (asla iç servise delege etmeden), iç servislerle mTLS veya servis token, log’larda PII maskeleme, schema validation gelen ve giden taraflarda, CORS politikası UI domainine kilitli, düzenli sızma testi. BFF’in yetkilendirme mantığını mikroservisle çiftlemek defense-in-depth sağlar; BFF düşse bile iç servis “deny by default” davranmalı. Secret yönetimi için Vault veya AWS Secrets Manager zorunlu.
BFF’ten ne zaman vazgeçmek gerekir?
BFF iki durumda yarardan çok zarar verir. Birincisi: tek bir UI tipiniz var (sadece web), trafik düşük, mikroservis sayınız 3 altında. Bu senaryoda BFF deployment overhead’i mimari değer üretmez; API gateway yeterli. İkincisi: BFF’iniz domain mantığını içine almış, mikroservislerle çift kayıt durumuna gelmiş, “BFF monolith” antipattern’ine düşmüş. Bu durumda çözüm BFF’i atmak değil; iş mantığını mikroservislere geri taşıyıp BFF’i aggregation/shaping katmanına indirgemek. Migration için Strangler Fig pattern uygundur.
Sonuç: Multi-Channel Ürünler İçin BFF Verdict’i
BFF pattern, mikroservis mimarisinin UI tarafındaki çekim kuvvetini taşıyan tampon katmandır. Doğru kurulduğunda p99 gecikmeyi yarıya indirir, frontend ekibine bağımsız hız kazandırır, istemci başına optimizasyon kapısını açar ve dönüşüm oranını %7-9 yukarı çeker. Yanlış kurulduğunda ise yeni bir monolite veya kontrol edilemez bir aggregation chaos’una dönüşür. Sam Newman’ın 2026 çıkacak güncel edisyonunda altını çizdiği üzere BFF, “frontend ekibinin backend yetisini sahiplenmesi” felsefesinin somutlaşmış halidir. Verdict: 2+ istemci tipi, 5+ mikroservis ve 10+ kişilik frontend ekibi varsa BFF kurun; tek istemci tipi veya 3 altı mikroservis varsa API gateway yeterli. Kapsamı dar tutun, domain mantığını sızdırmayın, iyi observe edin, ve her UI ekibine kendi BFF sahipliğini verin. Bu üç disiplin BFF’i mimarinizin en güçlü kaldıracına çevirir.
Ömer ÖNAL
Mayıs 16, 2026Yazılım danışmanlığı projelerinde sıkça karşılaştığım bir soru: “Hangi mimari hangi senaryoda öncelikli olmalı?” Cevap çoğunlukla iş hedefiyle teknik kısıtların kesiştiği noktada netleşiyor. Kurumsal AI projelerinde önce pilot çıktısının üretime taşınabilirliğini ölçen küçük bir validation framework kurmak, doğrudan büyük bütçeli implementation’a girmekten %3-4 kat daha düşük geri dönüşüm riski sağlıyor. Yorumlarınıza açığım.