Feature Flag ve A/B Testi Mimarisi

Geleneksel yazılım geliştirme süreçlerinde yeni bir özelliği canlı ortama taşımak (deployment), o özelliği aynı saniye içinde tüm kullanıcılara açmak (release) anlamına gelirdi. Haftalarca veya aylarca ayrı bir Git dalında (feature branch) geliştirilen binlerce satırlık kod, cuma akşamı ana dala (main/master) birleştirilip sunuculara yüklendiğinde; en ufak bir veritabanı darboğazı, bellek sızıntısı veya öngörülemeyen bir iş mantığı hatası tüm sürümün acilen geri alınmasını (rollback) ve saatler süren kesintileri beraberinde getirirdi. Modern DevOps ve Sürekli Teslimat (Continuous Delivery) mühendisliğinde ise bu risk, Dağıtım (Deployment) ile Yayınlama (Release) kavramlarının birbirinden tamamen ayrılmasıyla ortadan kaldırılmıştır. Bu mimari devrimin merkezinde ise Feature Flags (Özellik Bayrakları / Feature Toggles), Aşamalı Teslimat (Progressive Delivery), Canary Release ve Blue-Green Deployment stratejileri yer alır.

Günümüzde yüksek trafikli uygulama ve yazılım platformları (Netflix, Uber, Spotify, GitHub, Meta ve büyük finans kuruluşları), günde yüzlerce kez üretim sunucularına kod dağıtımı yaparken son kullanıcıların hiçbir kesinti yaşamamasını bu mimariye borçludur. Bu kapsamlı teknik rehberde; Özellik Bayraklarının (Feature Flags) kaputunun altında nasıl çalıştığını, yeniden derleme (redeploy) yapmadan milisaniyeler içinde devreye giren Acil Kapatma Anahtarı (Kill Switch) mekanizmasını, istatistiksel A/B testleri ile kullanıcı segmentasyonunu, Canary ve Blue-Green dağıtım topolojilerini ve "Bayrak Borcu" (Flag Debt) yönetimini derinlemesine inceliyoruz.

1. Temel Paradigma Değişimi: Dağıtım (Deployment) ≠ Yayınlama (Release)

Modern yazılım mimarisini anlamak için öncelikle sıklıkla birbirinin yerine kullanılan iki kavramı net bir çizgiyle ayırmak gerekir:

• Dağıtım (Deployment): Yazılan kodun derlenip (build), testlerden geçirilip üretim sunucularına, konteyner kümesine (Kubernetes) veya sunucusuz (serverless) altyapıya fiziksel olarak kopyalanması ve çalıştırılması işlemidir. Bu tamamen teknik ve altyapısal bir süreçtir.
• Yayınlama (Release): Sunucuda halihazırda bulunan bir özelliğin son kullanıcılara görünür ve kullanılabilir hale getirilmesi işlemidir. Bu tamamen ürün yönetimi ve iş (business) kararıdır.

Feature Flag (Özellik Bayrağı), kodunuzun içine yerleştirilen ve çalışma zamanında (runtime) merkezi bir kural motoru tarafından değerlendirilen dinamik bir karar noktasıdır. Yeni geliştirdiğiniz bir ödeme algoritmasını veya yapay zeka asistanını bir Feature Flag arkasına aldığınızda, kodu henüz tamamlanmamış olsa bile her gün ana dala (Trunk-Based Development) birleştirebilir ve üretim sunucularına dağıtabilirsiniz (Dark Launching / Karanlık Başlatma). Kod üretimde pasif olarak bekler; hiçbir kullanıcı bu kodu görmez. İstediğiniz gün ve saatte, tek bir satır kodu yeniden derlemeden veya sunucuları yeniden başlatmadan kontrol panelinden bayrağı açarak özelliği önce kendi iç ekibinize, sonra kullanıcıların %1'ine, ardından %100'üne açabilirsiniz. Böylece DORA (DevOps Research and Assessment) metriklerinin en önemli dört göstergesi olan Dağıtım Sıklığı (Deployment Frequency), Değişiklik Teslim Süresi (Lead Time for Changes), Değişiklik Hata Oranı (Change Failure Rate) ve Ortalama Kurtarma Süresi (MTTR) aynı anda optimize edilmiş olur.

2. Feature Flag Kategorileri: Hangi Bayrak Ne Amaçla Kullanılır?

Kurumsal bir yazılımda kullanılan tüm özellik bayrakları aynı yaşam döngüsüne veya aynı teknik amaca sahip değildir. Martin Fowler ve modern yazılım mimarisi literatürüne göre özellik bayrakları dört ana sınıfa ayrılır:

A. Yayın Bayrakları (Release Toggles)

Gövde Tabanlı Geliştirme (Trunk-Based Development) yapan ekiplerin, uzun süreli özellik dalları (long-lived feature branches) ve birleştirme cehennemi (merge hell) yaşamamak için kullandığı geçici bayraklardır. Tamamlanmamış kod parçalarının üretim ortamında gizli kalmasını sağlar. Özellik %100 oranında tüm kullanıcılara açıldıktan ve kararlılığı kanıtlandıktan sonra 1-2 hafta içinde koddan silinmelidir.

B. Operasyonel Bayraklar ve Acil Kapatma Anahtarı (Ops Toggles & Kill Switches)

Sistemin performansı ve erişilebilirliğiyle doğrudan ilişkili olan, genellikle uzun ömürlü veya kalıcı bayraklardır. Örneğin Kara Cuma (Black Friday) kampanyası sırasında veritabanı CPU kullanımı %90'ı aşarsa, Kill Switch (Acil Kapatma Anahtarı) olarak tanımlanmış bir operasyonel bayrak devreye girerek yüksek maliyetli "Kişiselleştirilmiş Ürün Önerileri" veya "Canlı Yorum Akışı" modüllerini milisaniyeler içinde kapatır ve ana ödeme akışının ayakta kalmasını (Graceful Degradation) sağlar.

C. Deney Bayrakları (Experiment Toggles / A/B Testing)

Ürün ekiplerinin veri odaklı karar almasını sağlayan çok değişkenli (multivariate) bayraklardır. Kullanıcıları deterministik bir özetleme (hashing) algoritmasıyla Kontrol Grubu (A) ve Deney Grubu (B veya C) olarak ayırır. Dönüşüm oranı (conversion rate), sepet tutarı veya tıklama oranı gibi iş metrikleri istatistiksel anlamlılığa (statistical significance - genellikle p-değeri < 0.05) ulaşana kadar açık kalır.

D. İzin ve Yetkilendirme Bayrakları (Permissioning Toggles)

Yalnızca belirli müşteri segmentlerine (örneğin "Enterprise Plan" abonelerine, "Erken Erişim / Beta" kullanıcılarına veya şirket içi QA mühendislerine) özel özellikleri açmak için kullanılan kalıcı bayraklardır. Özellikle kurumsal bulut çözümleri ve çok kiracılı (multi-tenant) SaaS yazılımlarında müşteri bazlı özellik yönetimi bu katmanla gerçekleştirilir.

3. Kaputun Altında Feature Flag Değerlendirme Mimarisi

Bir geliştirici if (featureFlags.isEnabled("new-checkout-flow", userContext)) yazdığında arka planda her istekte uzak bir sunucuya HTTP çağrısı mı yapılır? Eğer öyle olsaydı, her fonksiyon çağrısında 50-100 ms ağ gecikmesi yaşanır ve bayrak sunucusu çöktüğünde tüm uygulama dururdu. Modern Feature Flag sistemleri (LaunchDarkly, Unleash, Flagsmith, OpenFeature, GrowthBook) bu sorunu Yerel Değerlendirme (Local Evaluation) ve Akış (Streaming) mimarisiyle çözer:

1. Kural Seti Senkronizasyonu (SSE / WebSockets): Uygulama sunucusu (SDK) ayağa kalktığında, merkezi Feature Flag kontrol düzleminden (Control Plane) tüm bayrak kurallarını (JSON formatındaki kural ağacını) indirir ve kendi RAM önbelleğine yazar. Bir bayrak değiştirildiğinde Server-Sent Events (SSE) üzerinden 100-200 milisaniye içinde tüm sunucuların belleğindeki kural güncellenir.
2. Sıfır Ağ Gecikmeli Bellekte Değerlendirme: Bir kullanıcı isteği geldiğinde SDK hiçbir ağ çağrısı yapmaz; kullanıcının bağlamını (userId, country, plan, appVersion) bellekteki kural ağacıyla karşılaştırır ve mikrosaniyeler (< 0.05 ms) içinde sonucu döndürür.
3. Deterministik Yüzdelik Dağıtım (Consistent Hashing / MurmurHash3): Bir özelliği kullanıcıların %20'sine açtığınızda, aynı kullanıcının sayfayı her yenilediğinde farklı bir deneyim görmemesi (flickering olmaması) şarttır. Bunun için hash(flagKey + userId) % 100 formülüyle 0 ile 99 arasında deterministik bir kova (bucket) değeri üretilir. Kova değeri 20'nin altındaysa kullanıcı her zaman yeni özelliği görür; dağıtım oranı %20'den %50'ye çıkarıldığında ise mevcut %20'lik grup korunurken üzerine yeni %30 eklenir.

// CNCF Standardı OpenFeature SDK ile Tip Güvenlikli Bayrak Değerlendirmesi (TypeScript)
import { OpenFeature } from '@openfeature/server-sdk';

async function odemeSayfasiOlustur(kullanici: { id: string; ulke: string; kurumsalMi: boolean }) {
  const client = OpenFeature.getClient('odeme-servisi');

  // Kullanıcı bağlamı (Evaluation Context) tanımlanır
  const baglam = {
    targetingKey: kullanici.id,
    country: kullanici.ulke,
    tier: kullanici.kurumsalMi ? 'enterprise' : 'standard',
  };

  // Bellekte mikrosaniyeler içinde değerlendirilir (Varsayılan yedek değer: false)
  const tekTiklaOdemeAktifMi = await client.getBooleanValue('tek-tikla-kripto-odeme', false, baglam);

  if (tekTiklaOdemeAktifMi) {
    return yeniNesilOdemeAkisiniCalistir(kullanici);
  }
  return klasikOdemeAkisiniCalistir(kullanici);
}

4. Progressive Delivery: Canary Release, Blue-Green Deployment ve Feature Flags Karşılaştırması

Yazılım dağıtımında riski azaltmak için kullanılan Blue-Green Deployment, Canary Release ve Feature Flags kavramları birbirinin rakibi değil, farklı katmanlarda çalışan tamamlayıcı mimarilerdir. Aralarındaki teknik farkları netleştirelim:

Özellik / Kriter	Blue-Green Deployment	Canary Release (Kanarya Dağıtımı)	Feature Flags (Özellik Bayrakları)
Çalıştığı Katman	Altyapı / Ağ Katmanı (Load Balancer / Ingress)	Altyapı / Servis Ağı (Kubernetes / Istio / Envoy)	Uygulama Kod Katmanı (SDK / İş Mantığı)
Temel Çalışma Mantığı	Mevcut (Blue) ortamın yanına birebir aynı kapasitede yeni (Green) ortam kurulur; trafik tek seferde %100 aktarılır.	Yeni sürüm az sayıda sunucuya (Pod) kurulur; ağ trafiğinin önce %1'i, sonra %10'u, %50'si ve %100'ü kademeli yönlendirilir.	Kod tüm sunuculara dağıtılır; ancak özellik kod içindeki bayrakla kullanıcı kimliği/segmentine göre açılır.
Geri Alma (Rollback) Süresi	Saniyeler içinde (Yük dengeleyici yönlendirmesi Blue ortama geri çevrilir).	Saniyeler içinde (Canary pod'larına giden trafik %0'a çekilir).	Milisaniyeler içinde (Tek tıkla sadece ilgili bayrak kapatılır, diğer özellikler etkilenmez).
Hedefleme Hassasiyeti	Yoktur (Ya hep ya hiç).	Genellikle IP, Bölge veya Çerez/Header bazlı kaba trafik bölme.	Çok yüksek (Kullanıcı ID, abonelik paketi, cihaz sürümü, şirket adı bazlı mikro-hedefleme).
Altyapı Maliyeti	Yüksek (Geçiş anında iki kat sunucu kaynağı gerektirir).	Düşük (Yalnızca birkaç ek Canary pod'u çalışır).	Sıfır ek sunucu maliyeti (Mevcut uygulama belleğinde çalışır).
En Uygun Kullanım Senaryosu	İşletim sistemi, veritabanı sürücüsü veya ana çatı (framework) yükseltmeleri.	Yeni bir mikroservis sürümünün CPU/RAM ve HTTP 500 hata oranlarını gerçek trafikte doğrulama.	Yeni ürün özellikleri, A/B testleri, Acil Kapatma (Kill Switch), müşteri bazlı yetkilendirme.

5. A/B Testi Mimarisi ve İstatistiksel Tuzaklar

Bir Feature Flag altyapısını A/B Testi (Deneyleme Platformu) seviyesine taşıyan şey, bayrak değerlendirme olaylarının (exposure events) analitik veri ambarındaki dönüşüm olaylarıyla (conversion events) birleştirilmesidir. Ancak mühendislik ekiplerinin A/B testlerinde sıklıkla düştüğü üç kritik teknik tuzak vardır:

• Örneklem Oranı Uyuşmazlığı (Sample Ratio Mismatch - SRM): Deneyi %50 Kontrol (A) ve %50 Varyant (B) olarak ayarladığınız halde, 100.000 kullanıcının 52.300'ü A grubunda, 47.700'ü B grubunda toplanmışsa burada ciddi bir mühendislik hatası (SRM) vardır. Genellikle B varyantındaki kodun yavaş çalışıp sayfa terk oranını artırması veya önbellek (CDN) katmanının varyantı yanlış sunması SRM'ye yol açar ve deney sonuçlarını tamamen geçersiz kılar.
• Erken Gözetleme Hatası (Peeking Problem): Testi başlattıktan 2 gün sonra B varyantının %15 önde olduğunu görüp testi erkenden sonlandırmak, yanlış pozitif (False Positive - Tip I hata) oranını %5'ten %30'ların üzerine çıkarır. Güvenilir bir A/B testi için önceden belirlenen örneklem büyüklüğüne ulaşılmalı veya Ardışık Test (Sequential Testing / Bayesian istatistik) modelleri kullanılmalıdır.
• Karşılıklı Dışlama (Mutual Exclusion / Katmanlama): Aynı anda ödeme sayfasında hem "Buton Rengi Deneyi" hem de "Kargo Ücreti Gösterimi Deneyi" yapılıyorsa, iki deneyin birbirinin sonuçlarını kirletmemesi (interaction effect) için kullanıcı evreninin ortogonal katmanlara (layers) bölünmesi gerekir.

6. Güvenlik ve "Bayrak Borcu" (Flag Debt) Yönetimi

Özellik bayrakları muazzam bir çeviklik sağlasa da, disiplinli yönetilmediğinde yazılım mimarisini içinden çıkılmaz bir spagetti koda dönüştürebilir. Finans tarihinin en ünlü yazılım felaketlerinden biri olan Knight Capital Group vakası (2012), tam olarak temizlenmemiş eski bir Feature Flag yüzünden yaşanmıştır: 8 yıldır kullanılmayan ölü bir yüksek frekanslı ticaret (HFT) kodunu kontrol eden bayrak, yeni bir dağıtım sırasında yanlışlıkla tekrar tetiklenmiş ve şirket yalnızca 45 dakika içinde 440 milyon dolar zarar ederek iflasın eşiğine gelmiştir.

Bu tür felaketleri önlemek ve ayrıca yapay zeka destekli tersine mühendislik araçlarıyla istemci tarafı (mobil veya web ön yüzü) kodlarını inceleyen kişilerin henüz duyurulmamış gizli özellikleri keşfetmesini engellemek için şu 4 altın kural uygulanmalıdır:

1. Gizli Özellikleri İstemciye Göndermeyin: Henüz kamuya duyurulmamış stratejik ürün özelliklerinin veya Web3 akıllı sözleşme entegrasyonlarının bayrak değerlendirmesini tarayıcıda (JavaScript bundle içinde) değil, arka uç (Backend / SSR / Edge Worker) katmanında yapın.
2. Son Kullanma Tarihi (Expiration Date) ve Sahiplik: Oluşturulan her Release Toggle için bir sorumlu mühendis ve bir son kullanma tarihi (örneğin 30 gün) atanmalıdır. Süresi dolan bayraklar Slack/Jira üzerinden otomatik olarak teknik borç uyarısı üretmelidir.
3. Otomatik Kod Temizliği: %100 açık duruma gelmiş bayrakların if/else bloklarını kod tabanından otomatik temizlemek için AST (Soyut Sözdizimi Ağacı) tabanlı refactoring araçları veya otonom kod ajanları kullanılmalıdır.
4. Gözlemlenebilirlik ve Güvenlik Denetimi: Bir özellik bayrağının açılması veya kapatılması, üretim ortamına yapılan bir kod dağıtımı kadar kritiktir. Bu nedenle kurumsal siber güvenlik ve denetim standartları gereği, kritik bayrak değişiklikleri mutlaka "Dört Göz İlkesi" (onay mekanizması) ve değiştirilemez denetim kayıtları (Audit Logs) ile korunmalıdır.

Sıkça Sorulan Sorular (SSS)

1. Feature Flag kullanmak uygulamanın çalışma hızını (performansını) düşürür mü?

Hayır, doğru mimariyle kurgulandığında performans etkisi sıfıra yakındır. Modern Feature Flag SDK'ları (OpenFeature, Unleash, LaunchDarkly vb.) kural setlerini uygulama sunucusunun yerel RAM belleğinde tutar. Bir isEnabled() çağrısı ağ üzerinden başka bir sunucuya gitmez; doğrudan bellekteki bir JSON kuralını değerlendirir ve bu işlem 10 ila 50 mikrosaniye (saniyenin yüz binde biri) sürer.

2. Merkezi Feature Flag sunucusu çökerse uygulamamız da çöker mi?

Çökmez. Tüm kurumsal Feature Flag mimarileri Hata Toleranslı (Fail-Safe) olarak tasarlanır. Uygulama sunucularınız kural setinin son bilinen kopyasını yerel bellekte ve diskte önbelleğe alır; eğer merkezi kontrol sunucusu tamamen ulaşılamaz hale gelirse veya ilk açılışta bağlantı kurulamazsa, kod içinde tanımladığınız Varsayılan Değerler (Default Fallback Values) devreye girer ve uygulama kesintisiz çalışmaya devam eder.

3. Veritabanı şema değişikliklerinde (Database Migrations) Feature Flag nasıl kullanılır?

Veritabanı değişikliklerinde Feature Flag kullanırken Genişlet ve Daralt (Expand and Contract / Parallel Change) deseni uygulanır. Örneğin bir sütunun adını değiştirecekseniz; önce eski sütunu silmeden yeni sütunu eklersiniz (Expand), ardından bir Feature Flag ile uygulamanın hem eski hem yeni sütuna yazmasını (Dual Write) sağlarsınız, geçmiş verileri arka planda taşırsınız, okuma işlemini bayrakla yeni sütuna geçirirsiniz ve her şey kararlı olduğunda eski sütunu silersiniz (Contract).

4. Kendi Feature Flag sistemimizi mi yazmalıyız yoksa hazır bir araç mı kullanmalıyız?

Basit bir yapılandırma dosyasında (.env veya Redis üzerinde) true/false tutmak ilk başta kolay görünse de; yüzdelik dağıtım (consistent hashing), kullanıcı özniteliklerine göre kural yazma, A/B testi analitiği, gerçek zamanlı SSE senkronizasyonu ve denetim kayıtları (audit logs) gerektiğinde ev yapımı sistemler hızla yetersiz kalır. Kendi altyapınızda barındırmak istiyorsanız Unleash, Flagsmith veya GrowthBook gibi açık kaynaklı çözümleri CNCF standardı olan OpenFeature SDK ile birlikte kullanmak en sağlıklı yaklaşımdır.

5. Kod tabanında aynı anda kaç tane aktif Feature Flag bulunmalıdır?

Kalıcı operasyonel bayraklar (Kill Switches) ve kurumsal paket yetkilendirme bayrakları hariç tutulursa, bir mikroserviste veya ön yüz projesinde aktif Yayın Bayrağı (Release Toggle) sayısının 10-20 bandını aşmaması önerilir. Yeni bir bayrak eklemeden önce %100'e ulaşmış eski bir bayrağı koddan temizlemek ("Bir Bayrak Girdi, Bir Bayrak Çıktı" kuralı), test kombinasyonlarının patlamasını ve teknik borcu önlemenin en etkili yoludur.