Skip to main content

> tedarikçi_dayanıklılığı:_üçüncü_taraf_saas_çökmelerini_yönetme,_devre_kesiciler_(circuit_breakers)_ve_kademeli_bozulma_(graceful_degradation)

Tedarikçi Dayanıklılığı: Üçüncü Taraf SaaS Çökmelerini Yönetme, Devre Kesiciler (Circuit Breakers) ve Kademeli Bozulma (Graceful Degradation)

Stripe, Twilio veya Cloudflare gibi harici bir sağlayıcının çökmesi sizin uygulamanızı neden tamamen kilitler; otomatik devre kesiciler ve asenkron kuyruklar tedarikçi arızalarını nasıl yalıtır?

Senior (L5)

⚡ÖZET VE TEKNİK CEVAP

Modern mikroservis uygulamaları onlarca harici SaaS sağlayıcısına bağımlıdır (Ödeme için Stripe, SMS için Twilio, arama için Algolia, e-posta için SendGrid). Harici bir sağlayıcı çöktüğünde veya aşırı yavaşladığında (yanıt vermesi 30 saniye sürdüğünde), zayıf backend mimarileri ölümcül bir hata yapar: Ölü sağlayıcıyı beklerken sunucu iş parçacıklarını (threads) senkron olarak kilitlemek. 60 saniye içinde tüm web sunucu bağlantı havuzları tükenir ve kendi iç veritabanınız tamamen sağlam olmasına rağmen tüm uygulamanız çöker. Dayanıklılık mühendisliği Tedarikçi Arıza Yalıtımı ve Kademeli Bozulma (Graceful Degradation) uygular:

1

Devre Kesiciler (Circuit Breakers - Resilience4j / Opossum): Üst üste 5 zaman aşımından sonra devreyi açarak harici servisi çağırmayı durdurur ve iş parçacıklarını kilitlemeden 1 milisaniyede hata döner.

2

Asenkron Kuyruklar (DLQ): E-posta ve SMS gibi kritik olmayan işler dayanıklı SQS/Kafka kuyruklarına atılarak sağlayıcı düzeldiğinde tekrar denenmek üzere saklanır.

3

Zarif Arayüz Koruması: Tüm sayfayı çökertmek yerine kullanıcıya zarif bir alternatif bildirim gösterilir.

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma

Tedarikçi dayanıklılığı 3 mimari katmanla çalışır:

1

Devre Kesici Durum Makinesi: Hata oranını takip eder; son 20 istekte hata oranı %50'yi aşarsa devre CLOSED (Kapalı) durumundan OPEN (Açık) durumuna geçer; harici servise gitmeden 30 saniye boyunca doğrudan önbellek veya alternatif veriyi döner.

2

Agresif Zaman Aşımları: Tüm harici HTTP istemcilerine katı bağlantı (<1 sn) ve okuma (<3 sn) zaman aşımları konulur.

3

Asenkron İş Kuyrukları: E-posta/SMS gönderimleri arka plan BullMQ işçilerine devredilir.

4

Çoklu Sağlayıcı Yedeği: SMS ve e-posta gibi kritik kanallarda Twilio çöktüğünde devre kesici otomatik olarak trafiği MessageBird veya Postmark'a aktarır.

🎯2. Doğru Kullanım Senaryosu

Kapsam

Harici ödeme sistemleri entegrasyonu, SMS/E-posta servisleri, özellik bayrağı (feature flag) altyapıları ve harici arama motoru arıza yalıtımı.

⚠️3. Prodüksiyon Arıza Modları

Kritik Risk
  • ✓

    Harici bir pazarlama takip script'inin 45 saniye yanıt vermeyip tarayıcıyı kilitlemesi ve müşterilerin satın alma butonunu görememesi

  • ✓

    çöken bir e-posta sağlayıcısını bekleyen backend sunucularının tüm belleği tüketip kilitlenmesi

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler
  • ✓

    Twilio veya Stripe çöktüğünde şirketin kendi uygulamasının da çökmesi

  • ✓

    harici sağlayıcı arızalarında sunucu iş parçacığı havuzunun dolup kilitlenmesi

  • ✓

    HTTP isteklerinde zaman aşımı ayarlarının bulunmaması

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler
  • ✓

    Tüm harici API çağrılarını Devre Kesicilerle (Circuit Breakers) sarmalayın

  • ✓

    1 saniyenin altında agresif zaman aşımları tanımlayın

  • ✓

    kritik olmayan tüm dış istekleri asenkron kuyruklara aktarın

⚖️6. Mimari Ödünleşimler (Trade-offs)

Ödünleşim

Devre kesiciler harici sağlayıcı çökmelerinin uygulamanızı çökertmesini önler; ancak her harici servis için zarif bir alternatif kullanıcı deneyimi (UX Fallback) tasarlamayı gerektirir.

📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

Bir e-ticaret uygulaması ödeme ekranında harici bir adres doğrulama servisini senkron çağırıyordu. Bu harici servis küresel bir kesinti yaşayıp 60 saniye boyunca yanıt vermeyince, gelen tüm ödeme istekleri askıda kaldı, backend sunucu havuzu kilitlendi ve tüm mağaza 3 saat boyunca çöktü. Mühendislik ekibi mimariyi baştan tasarladı:

1

Harici servisi 1.5 saniye zaman aşımlı bir Opossum devre kesiciyle sarmaladı,

2

Servis çökerse devre açılarak kullanıcıya manuel adres girişi izni veren zarif bir yedek akış açıldı, ve

3

Adres doğrulaması arka plan kuyruğuna atıldı. 2 ay sonra aynı harici servis tekrar çöktüğünde devre kesici 3 saniyede açıldı, kullanıcılar alışverişlerine kesintisiz devam etti ve rakipler kapalıyken şirket $850.000 satış yaptı.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

Dağıtık sistemlerde bir Devre Kesici (Circuit Breaker) modelinin 3 temel durumu nedir?

1. CLOSED (Kapalı / Normal: İstekler harici servise gider), 2. OPEN (Açık / Arıza: Eşik aşıldığında istekler harici servise hiç gitmeden anında hata/yedek veri döner), ve 3. HALF-OPEN (Yarı Açık: Sağlayıcının düzelip düzelmediğini anlamak için deneme isteği gönderir).
Q2

Harici bir SaaS servisi çöktüğünde 'Kademeli Bozulma' (Graceful Degradation) nedir?

Tüm kullanıcı deneyimini çökertmek yerine; uygulamanın ikincil ve kritik olmayan özellikleri geçici kapatarak (ör. adres otomatik tamamlama yerine manuel girişe izin vererek) ana işlevini sürdürmesini sağlayan mimari yaklaşımdır.

Tedarikçi Dayanıklılığı: Üçüncü Taraf SaaS Çökmelerini Yönetme, Devre Kesiciler (Circuit Breakers) ve Kademeli Bozulma (Graceful Degradation) — Sıkça Sorulan Sorular

Bir HTTP istemcisine zaman aşımı (timeout) koymamak neden ölümcül bir mimari kusurdur?

Çünkü varsayılan HTTP istemcileri yanıt gelene kadar sonsuza kadar (veya 15 dakika) bekler; bu da gelen kullanıcı trafiğinin tüm sunucu iş parçacıklarını anında tüketmesine ve tüm sistemin kilitlenmesine yol açar.

E-posta veya webhook gibi bloklamayan harici bildirimler nasıl mimarilendirilmelidir?

Kullanıcı HTTP yanıtını harici servisten tamamen ayırmak için; bu işleri üstel geri çekilmeli (exponential backoff) asenkron kuyruk sistemlerine (SQS, Kafka, BullMQ) devrederek.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸

    Harici servis yavaşlıkları sunucu iş parçacıklarını tüketerek uygulamanızı çökertir.

  • ▸

    Tüm harici API çağrılarını Devre Kesicilerle (Circuit Breakers) sarmalayın.

  • ▸

    Tüm harici HTTP istemcilerine 1 saniyenin altında katı zaman aşımları koyun.

  • ▸

    Ana iş akışlarını ayakta tutmak için kademeli bozulma (fallback) deneyimleri tasarlayın.

Yaygın Yanılgılar

  • ✗

    Yanılgı: Harici servis çökmeleri bizim elimizde değildir, dolayısıyla kesinti bizim suçumuz sayılmaz (Gerçek: Müşteri sizi sorumlu tutar; olgun mimariler dış arızaları tamamen yalıtır).

  • ✗

    Yanılgı: Zaman aşımı süresini uzatmak harici servisin yanıt vermesine fırsat tanır (Gerçek: Uzun süreler sadece sizin sunucularınızın kilitlenmesini garantiler).

Karar Kılavuzu & Önceliklendirme

Harici sağlayıcı çökmelerinin sisteminizi kilitlemesini önlemek için tüm entegrasyonlarda Devre Kesiciler, agresif zaman aşımları ve asenkron yedek kuyruklar kullanın.

Doğrulanmış Kaynaklar & Referanslar