Özellik bayrakları (Kill Switch)

Kısaca: Çalışma zamanında çevrilebilen bir anahtar; bununla tekil, kritik olmayan özellikler bir dağıtım yapmadan açılıp kapatılabilir — örneğin yüksek sunucu yükünde kısa sürede kapatmak için.

Biraz daha ayrıntılı: Önemli olan, böyle bir anahtarla değiştirilebilecek “olsa iyi olur” özellikler ile asla onunla devre dışı bırakılmaması gereken kritik çekirdek işlevler (ödeme, giriş) arasındaki bilinçli ayrımdır — aksi hâlde bir “yükü azalt” anahtarı kazara bir “geliri kapat” anahtarına dönüşür. Depolama sisteminin kendisi (burada Redis) çökerse, yedek davranış her zaman “her şey açık” olmalı, asla “her şey kapalı” değil.

Bizim bağlamımız: Emzett’te app/utils/featureFlags.ts, Postgres’teki site_settings tablosu yerine bilerek Upstash Redis kullanır — kill switch’in tüm amacı sistem yük altındayken ek Postgres okumaları OLUŞTURMAMAKTIR. Şu anda yalnızca ses efektleri ve değerlendirme açılır penceresi için kullanılır, Lambda örneği başına 30 sn’lik bellek içi önbellekle.

Ayrıntılı

Pratikte özellik bayrakları, gereksinimleri belirgin biçimde farklı çok değişik amaçlar için kullanılır: kill switch’ler (bu kavram — acil durumda bir şeyi hızla kapatmak, genellikle ikili aç/kapa, tüm kullanıcıları eşit etkiler), kademeli sunumlar (yeni bir özelliği önce kullanıcıların %5’i için etkinleştirip yavaşça artırmak, hatalı bir sürümün riskini sınırlamak için) ve A/B testleri (hangisinin daha iyi çalıştığını ölçmek için farklı kullanıcı gruplarına paralel iki varyant sunmak). Kill switch’lerin tepki süresi gereksinimleri en sertidir — acil durumda (örneğin hatalı, yük üreten bir işlev) anahtarın henüz etkili olmadığı her saniye önemlidir.

Örnek başına bellek içi önbellek, tutarlılık ile hız arasında bilinçli bir uzlaşmadır: bir bayrağı değiştirirsen tüm sunucu örneklerinin yeni değeri alması (hemen yerine) 30 saniyeye kadar sürer, ama karşılığında her istek yeni bir Redis gidiş-dönüşüne yol açmaz. Şüphede “hemen” değil “bir dakika içinde” etkili olması gereken bir kill switch için bu kabul edilebilir bir ödünleşimdir — bir ödeme yayımı için bu gecikme kabul edilebilir olmayabilir.

Fail-open ve fail-closed

Her özellik bayrağı sistemindeki merkezi bir tasarım kararı, bayrak kaynağının kendisine (burada Redis) ulaşılamadığında nasıl davranacağıdır: fail-open, şüphede özelliğin AÇIK sayılması demektir (bayrak getirilmeden önceki normal durum) — kritik olmayan özellikler için mantıklı, çünkü kısa süre etkin bir özellik yanlışlıkla kapatılmış olandan daha zararsızdır. Fail-closed tersidir, şüphede KAPALI — güvenlikle ilgili bayraklar için mantıklı (örneğin henüz bitmemiş, potansiyel hatalı bir ödeme işlevini denetleyen bir bayrak). Bir kill switch sistemi pratikte neredeyse her zaman fail-open olmalıdır, çünkü amacı tam olarak mevcut, çalışan özellikleri kapatmaktır — bayrak altyapısının kendisi çökerse bu otomatik olarak TÜM özellikleri de kapatmamalıdır.

Ortam değişkenlerinden farkı

Gerçek bir özellik bayrağı sistemine daha basit bir alternatif düz ortam değişkenleridir — ancak onları değiştirmek her zaman yeni bir dağıtım gerektirir, çünkü yalnızca bir süreç başlarken okunurlar. Redis/bir veritabanı üzerinden bir kill switch ise çalışma zamanında, dağıtım olmadan ve çalışan sunucu örneklerini yeniden başlatmadan değiştirilebilir — acil durumda tam olarak önem taşıyan zaman kazancı budur.

Ayrıca bak: Upstash Redis, Oran sınırlama, Hizmet