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

> Kritik akışı (gez, sepet, ödeme) lüks bileşenlerden ayırın, lüksleri kısa timeout'lu feature flag arkasına koyun, kill-switch'i kriz gelmeden prova edin.

- Soruldu: 2026-05-28
- Yanıtlandı: 2026-05-31
- Soran: Hakan
- Etiketler: dayaniklilik, mimari, olcekleme
- Kaynak: https://www.muhammetsafak.com.tr/sor-bakalim/graceful-degradation-kritik-olmayan-servisleri-izole-etmek/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
**Soru:** Black Friday'de sisteme aşırı yük bindi, DB CPU'su %98'e ulaştı. Sitenin tamamen çökmesini engellemek için graceful degradation uygulamak istiyorum.

Kullanıcı sepete ekleyip ödeme yapabilirken "Önerilen Ürünler", "Benzer Ürünler", "Yorumlar" gibi kritik olmayan servisleri dinamik olarak nasıl kapatır ya da sahte veriye yönlendiririm?


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 kapat 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.

## İlgili Yazılar

- [Üçüncü parti API bağımlılığında Circuit Breaker'ı nasıl kurarım?](https://www.muhammetsafak.com.tr/sor-bakalim/ucuncu-parti-api-icin-circuit-breaker-deseni/) — Sor Bakalım
- [Multi-tenant SaaS'ta veritabanı izolasyonu: ayrı DB mi, şema mı, tenant_id mi?](https://www.muhammetsafak.com.tr/sor-bakalim/multi-tenant-saas-veritabani-izolasyon-stratejisi/) — Sor Bakalım
- [Yerel diskteki dosyaları S3'e taşırken EFS ara çözüm olur mu?](https://www.muhammetsafak.com.tr/sor-bakalim/yerel-diskten-s3-e-gecerken-efs-ara-cozum-mu/) — Sor Bakalım