Graceful degradation: kritik olmayan servisleri yük altında nasıl izole ederim?

Kısa cevap: Graceful degradation bir kod tekniği değil, bir önceden karar verme disiplinidir. Neyin kritik, neyin lüks olduğuna Black Friday gelmeden karar ver; gerisi flag açıp kapatmak.

Asıl problem şu: %98 CPU’da hangi servisi kapatacağını düşünmeye başlarsan çoktan kaybetmişsindir. Çekirdek akış (ürünü gez, sepete at, ödeme yap) her zaman ayakta kalmalı; “olsa iyi” olanlar feda edilebilir olmalı.

1. Kritik ile lüksü ayır ve etiketle. Gez, sepet, checkout kritik. Önerilen ürünler, benzer ürünler, yorumlar lüks. Her lüks bileşeni bağımsız kapatılabilir bir feature flag arkasına al. Karar bugün verilmeli, kriz anında değil.
2. Her lüks servise kısa timeout + statik fallback koy. Öneri servisi 200ms’de cevap vermezse bekleme — boş dön ya da cache’lenmiş/mock listeyi göster. Böylece yavaş bir öneri servisi checkout’u asla aşağı çekemez.
3. Kill-switch ile anında devre dışı bırak. Yük altında tek bir flag’le tüm lüks bileşenleri kapatabil ya da mock veriye yönlendir. Bu, deploy gerektirmeyen, canlıda anında etki eden bir anahtar olmalı.
4. Load shedding ile DB’yi koru. Kritik olmayan endpoint’ler için erkenden 503 dön; o istekleri DB’ye hiç ulaştırma. Birkaç saniye fazladan yük binmeden veritabanını kurtarmanın yolu, talebi kapıda reddetmek.
5. Çekirdek yolu bulkhead ile izole et. Kritik ve kritik olmayan trafiğe ayrı bağlantı havuzu / worker ayır. Böylece lüks trafiğin patlaması checkout’un bağlantı havuzunu açlığa düşüremez.

Sonuç: Ben olsam flag’leri ve fallback’leri önceden kurar, “Black Friday anahtarlarını” gün gelmeden prova ederdim. Test edilmemiş bir kill-switch, kriz anında çalışacağına dair bir tahmindir. %98 CPU’da doğaçlama yapmak değil, önceden tanımlanmış bir senaryoyu çalıştırmak istiyorsun.