Feature Flag Mimarisi: OpenFeature ile Güvenli Yayınlama

Bir özelliği geliştirip tek seferde production'a almak, özellikle yoğun trafiği olan sistemlerde gereksiz risk üretir. En iyi test süreçleri bile gerçek kullanıcı davranışını birebir simüle edemez. Bu yüzden modern ekipler "release" ile "deploy" kavramını birbirinden ayırır: kodu production'a deploy eder, özelliği ise kontrollü biçimde açar. Bu kontrol katmanının adı feature flag'dir.

Feature flag, teknik olarak basit bir if koşulu gibi görünür; fakat doğru kullanılmadığında kod tabanını hızla karmaşıklaştırır. Başarılı kullanım için sadece koda değil, organizasyonel akışa da bakmak gerekir: kim flag açar, hangi metrik izlenir, rollback nasıl yapılır, eski flag ne zaman silinir?

Neden Feature Flag?

Feature flag yaklaşımı dört kritik problemi çözer:

1. Risk azaltma: Yeni davranışı önce %1 kullanıcıya açıp izlersin.
2. Hızlı geri alma: Sorun olursa deploy beklemeden flag kapatırsın.
3. Deney yönetimi: A/B test veya segment bazlı deney kolaylaşır.
4. Operasyonel esneklik: Yoğun saatlerde pahalı özelliği kapatabilirsin.

Mimari Akış

                +----------------------+
Request ------> | Application Service  |
                +----------+-----------+
                           |
                           v
                +----------------------+
                | OpenFeature SDK      |
                +----------+-----------+
                           |
                 evaluate("new_checkout")
                           |
                           v
                +----------------------+
                | Flag Provider        |
                | (LaunchDarkly,       |
                |  Flagsmith, custom)  |
                +----------+-----------+
                           |
                           v
                    true / false / variant

Bu akışın kritik noktası OpenFeature'dır. Uygulama kodu doğrudan bir vendor SDK'sına bağımlı olmaz. Sağlayıcı değiştiğinde iş mantığını değil, provider katmanını değiştirirsin.

OpenFeature ile Sağlayıcı Bağımsızlık

Go servisinde tipik kullanım şu mantıktadır:

• Uygulama başlangıcında provider kayıt edilir.
• Her request için kullanıcı bağlamı (country, plan, tenant, role) oluşturulur.
• Flag sonucu bool, string veya object varyantı olarak okunur.
• Hata durumunda güvenli default döndürülür.

Bu yaklaşım "vendor lock-in" riskini azaltır. Bir ürünün fiyatı yükseldiğinde veya on-prem ihtiyacı doğduğunda geçiş maliyeti dramatik biçimde düşer.

Rollout Stratejisi

Güvenli yayın için önerilen sıralı plan:

Adım 1: Internal only (sadece ekip)
Adım 2: Beta kullanıcılar (%5)
Adım 3: Bölgesel açılım (ör. sadece TR)
Adım 4: Trafik yüzdesi (%10 -> %25 -> %50)
Adım 5: Global %100 + flag temizliği

Her adımda şu metrikler zorunlu izlenmelidir:

• P95/P99 gecikme
• Hata oranı (5xx, domain error)
• İş metrikleri (checkout conversion, ödeme başarısı)
• Kaynak tüketimi (CPU, DB bağlantı sayısı)

Rollout sadece "sistem ayakta" kriterine göre değil, iş metriği sağlıklıysa ilerletilmelidir.

Flag Türleri ve Yaşam Döngüsü

Her flag aynı amaçla açılmaz:

• Release flag: Yeni özelliği kademeli açmak için, kısa ömürlü.
• Ops flag: Üretimde operasyonel kontrol için, orta-uzun ömürlü.
• Experiment flag: A/B test için, analiz sonrası kapanmalı.
• Permission flag: Plan/rol bazlı erişim için, kalıcı olabilir.

En kritik kural: Flag borcu birikir. Kapanmış release flag'leri kodda bırakmak, karar ağacını gereksiz büyütür ve hata olasılığını artırır. Bu nedenle her flag oluşturulurken "silinme tarihi" belirlenmelidir.

Sık Yapılan Hatalar

1. Flag'e config gibi davranmak: Her ayar flag olmamalı.
2. Default davranışı belirsiz bırakmak: Provider erişilemezse ne olacak?
3. Test matrisini büyütmemek: Flag açık/kapalı iki farklı sistem davranışıdır.
4. Observability koymamak: Hangi request hangi varyanta düştü bilinmezse debug zorlaşır.

Production İçin Pratik Kontrol Listesi

• Her flag için owner ve son kullanma tarihi var mı?
• Flag değerlendirme süresi (latency) ölçülüyor mu?
• SDK cache/polling ayarları trafik modeline uygun mu?
• Provider down olduğunda güvenli fallback tanımlı mı?
• CI'da eski flag'leri raporlayan bir kural var mı?

Feature flag disiplini, sadece "toggle koyma" tekniği değildir; yazılım teslimatını güvenli, ölçülebilir ve geri alınabilir hale getiren bir yayın mühendisliği yaklaşımıdır. OpenFeature ise bu yaklaşımı sağlayıcı bağımsız, sürdürülebilir ve geleceğe açık bir mimariye taşır. Doğru uygulandığında ekipler daha sık deploy eder, daha az incident yaşar ve değişimi korkmadan yönetir.