Burada ne görüyorsunuz

Kullanıcılar checkout-svc’yi çağırıyor, o da payments-api’yi. API aynı anda yaklaşık on iki çağrıyı kaldırabiliyor; bunun üstünde yavaşlıyor, yavaşladıkça da çağrılar birikiyor. Her çağrının bir saniyelik client timeout’u var — client vazgeçtiğinde API bunu bilmiyor: terk edilmiş çağrı üzerinde çalışmaya devam ediyor (içi boş noktalar) ve kimsenin kullanmayacağı kapasiteyi yakıyor.

Retry’lar bir kesintiyi neden kötüleştirebilir

Hemen tekrar denemek dayanıklılık gibi hissettirir; ama API aşırı yük yüzünden hata veriyorsa her retry daha fazla yük demektir. Üç anlık retry ile API, tam da en az kaldırabileceği anda gerçek trafiğinizin iki üç katını görebiliyor — “API’ye yük” değeri bunu gösteriyor. Full jitter’lı exponential backoff, retry’ları dağıtıp senkron dalgalar halinde gelmelerini engelliyor; ama ölü bir bağımlılığı canlandıramıyor.

Breaker aslında ne yapıyor

Breaker son yirmi çağrının sonucunu sayıyor. En az yarısı hata ya da timeout ile bittiyse devre açılıyor: çağrılar bir saniye bekleyip patlamak yerine anında bir fallback ile (cache’lenmiş ya da kısıtlı bir cevap) yanıtlanıyor ve API’ye toparlanması için alan kalıyor. Bekleme süresinden sonra half-open’a geçip üç deneme çağrısını geçiriyor; başarılı olurlarsa kapanıyor, biri patlarsa tekrar açılıyor. resilience4j, Polly ya da opossum’daki yapı da bu — patlayan bir bağımlılık size thread değil, milisaniye kaybettirmeli.

Sayılar bir model, benchmark değil; noktalar görülebilsin diye her şey gerçek zamandan 2.5 kat yavaş çalışıyor. Ama ödünleşim gerçek: fazla hevesle açılan bir breaker, aslında sorunsuz cevap alacak kullanıcılara fallback sunar. Bu yüzden eşik, pencere boyutu ve anlamlı bir fallback, desenin kendisi kadar önemli.