Failure Modes: Çökme Modları

// 1) Zamanlanmis is: sabit saniye yerine 0-30 sn kaydir
long kaydir = ThreadLocalRandom.current().nextLong(30_000);
long gecikme = acilisZamaniMs - System.currentTimeMillis() + kaydir;
zamanlayici.schedule(is, gecikme, TimeUnit.MILLISECONDS);   // ScheduledExecutorService: delay + birim

// 2) TTL: sabit degil, +-%20 sapma ile
int ttl = 300;
int sapma = ThreadLocalRandom.current().nextInt(-60, 61);
redis.setex(anahtar, ttl + sapma, deger);

// 3) Acilista kademeli baslatma: pod index'ine gore bekle, ama ust sinirli
int sira = podIndexiniOku();            // StatefulSet ordinal; Deployment'ta ordinal YOK
long bekle = Math.min(sira * 500L, 15_000L)               // 120 pod'da son pod 60 sn beklemesin
           + ThreadLocalRandom.current().nextLong(500);   // + jitter
Thread.sleep(bekle);

Üçüncüsünde iki tuzak var. sira * 500’ü sınırsız bırakırsan 120 gateway’de son pod 60 saniye bekler; üst sınır + jitter gerekir. Ordinal yalnızca StatefulSet’te var; Deployment’ta pod adının hash’ini kullanırsın ve hash düzgün dağılmayabilir — 20 pod’un 8’i aynı dilime düşebilir. Bu yüzden jitter hash’li sürümde süs değil, zorunluluk. Bir de bu bekleme açılışı 15 saniyeye kadar geciktiriyor: 5. bölümdeki startupProbe (failureThreshold × periodSeconds) bu 15 saniyeyi de kapsamalı, yoksa liveness kendi koyduğun beklemeyi “açılamadı” sayıp pod’u öldürür.

Yukarıdaki üç ilaç listedeki dört kaynağın üçünü çözüyor: cron, TTL, toplu restart. Köprülerin sağlayıcılara bağlanması da senin kodun, aynı kademeli açılışa girer. Ama gece duran istemcilerin yeniden bağlanması senin kodun değil; 09:00:00’da bütün terminallerin aynı saniyede TLS handshake + login + abonelik göndermesini istemci tarafından düzeltemezsin. Sunucu tarafı cevabı var ve dört parça:

• Accept rate limit. Yeni bağlantıyı saniyede N ile kabul et (yük dengeleyicide ya da uygulamada); fazlası kuyrukta değil, reddedilmiş olsun. Bağlantıyı kabul edip 20 saniye bekletmek istemciye timeout, sana yarım kalmış handshake demek.
• Jitter’lı Retry-After ile reddet. 3. bölümdeki load shedding’in bağlantı düzeyindeki hâli: “3–8 saniye sonra gel” diyen bir red, tek saniyeye yığılan bağlantıyı 5 saniyeye yayar.
• Bağlantı başına kademeli iş. Handshake’i kabul et, login’i ve ilk aboneliği ayrı ayrı sınırla; en pahalı adım (sembol listesini yollamak) en son ve en sıkı sınırlı olsun.
• IP / hesap başına limit. Reconnect döngüsüne girmiş tek bir istemcinin bütün accept bütçesini yemesini önler.

İstemci SDK’sını sen dağıtıyorsan bir beşincisi: jitter’lı exponential backoff’u SDK’ya göm, “bağlantı kopunca hemen tekrar dene” davranışını istemciye bırakma. Sabit 1 saniye bekleyen bir SDK, her kopuşta bütün terminalleri aynı saniyede kapıya getirir.

Toplu yeniden başlatmanın öbür yarısı pod’ların kapanışı. Deploy’da pod SIGTERM alıp hemen çıkarsa iki şey olur: elindeki in-flight istekler yarım kalır ve yük dengeleyici birkaç saniye daha ona istek yollamaya devam eder, çünkü endpoint listesinden düşmesi anlık değil. O istekler hata alır, istemci retry yapar, retry kalan pod’lara biner. Aynı çığ, bu kez kapanış tarafında; ve her deploy’da.

# Deployment
lifecycle:
  preStop:
    exec: { command: ["sh", "-c", "sleep 5"] }   # endpoint listesinden dusmeyi bekle, SIGTERM ondan sonra gelir
terminationGracePeriodSeconds: 30                 # preStop (5) + in-flight islerin bitmesi + kapanis; kucukse SIGKILL

# Uygulama (Spring): SIGTERM'de yeni istek alma, eldekini bitir, sonra cik
server.shutdown=graceful
spring.lifecycle.timeout-per-shutdown-phase=20s

Sıra: önce listeden düş (preStop beklemesi ya da readiness’i 503’e çekmek), sonra yeni bağlantı alma, sonra eldekini bitir, en son kapan. terminationGracePeriodSeconds bu toplamdan küçükse kubelet süreci SIGKILL ile keser ve bütün özen boşa gider.

// Deger ile birlikte "hesaplamasi ne kadar surdu" ve "ne zaman doluyor" saklanir.
// Sure dolmaya yaklastikca YENILEME OLASILIGI artar.

Kayit k = oku(anahtar);              // deger + hesapSuresi + bitis birlikte saklanir
// DIKKAT: kalan, hesapSuresi ve esik AYNI birimde (ms) olmali; biri saniye olursa formul sessizce bozulur
if (k == null) return hesaplaVeKaydet(anahtar).deger;   // ilk okuma: henuz deger yok (Kayit degil, deger doner)

long kalan = k.bitis - simdi();
double u = 1.0 - ThreadLocalRandom.current().nextDouble();     // (0, 1]: log(0) = -sonsuz tuzagi yok
double esik = -k.hesapSuresi * BETA * Math.log(u);             // BETA ~ 1.0

if (kalan < esik) {
    k = hesaplaVeKaydet(anahtar);     // erken, KENDILIGINDEN, tek basina
}
return k.deger;                        // yenilemeyen istemci de gecerli degeri doner

Güzelliği şurada: kilit yok, koordinasyon yok. İstemcilerin yalnızca birkaçı süre dolmadan önce yeniliyor, geri kalanı geçerli değeri okuyor. Süre hiçbir zaman “herkes için aynı anda” dolmuyor. Ve hesaplama ne kadar pahalıysa yenileme o kadar erken başlıyor — formül bunu kendiliğinden ayarlıyor.

// Varsayilan zaman asimi genelde YOK ya da 30+ saniye. Trade tarafinda 30 sn = sonsuz.
// Baglanti (connect) ve okuma (read) zaman asimi AYRI seylerdir:
// TCP/TLS handshake asili kalirsa read timeout hic devreye girmez.

// Redis (Jedis 4+): timeout constructor'a config ile verilir, setTimeout diye bir metot yok
JedisClientConfig cfg = DefaultJedisClientConfig.builder()
    .connectionTimeoutMillis(100)       // baglanti
    .socketTimeoutMillis(200)           // okuma: olculen p99 ~120 ms x 1,5
    .build();
JedisPoolConfig havuz = new JedisPoolConfig();
havuz.setMaxWait(Duration.ofMillis(100));   // havuzdan baglanti alma (checkout): varsayilan -1 = SINIRSIZ
JedisPool pool = new JedisPool(havuz, new HostAndPort(host, 6379), cfg);

// MT5 koprusu (HTTP)
HttpClient http = HttpClient.newBuilder()
    .connectTimeout(Duration.ofMillis(200))                    // baglanti
    .build();
HttpRequest istek = HttpRequest.newBuilder(uri)
    .timeout(Duration.ofMillis(800))                           // alisverisin TAMAMI, cevap bitene kadar: p99 ~500 ms x 1,5
    .build();

// Veritabani: sorgu suresi, havuzdan baglanti ALMA suresini kapsamaz
hikari.setConnectionTimeout(500);   // checkout: Hikari'de varsayilan 30 sn; DBCP2'de (maxWaitMillis=-1) SINIRSIZ
stmt.setQueryTimeout(3);            // sorgunun kendisi (saniye); surucuye bagli, PostgreSQL'de statement_timeout daha guvenilir

Üç ayrı timeout var ve görünmez olanı üçüncüsü: havuzdan bağlantı bekleme. Connect ve read ayarlanır, checkout unutulur. Varsayılanlar kütüphaneye göre değişir: HikariCP’de 30 saniye (trade tarafında sonsuzla aynı şey), DBCP2’de ve JedisPool’un altındaki GenericObjectPool’da maxWaitMillis = -1, yani gerçekten sınırsız. Dikkat: checkout’u sınırsız olan havuz bu yazının kendi Redis yolunda duruyor; yukarıdaki socketTimeoutMillis(200) havuzdan bağlantı aldıktan sonra başlar. Havuzdaki 20 bağlantının hepsi yavaş sorgularda takılınca 21. istek sessizce beklemeye başlar — timeout’u yoktur, çünkü henüz bir bağlantısı bile yoktur. Kaskadın gerçek başlangıç noktası çoğu zaman burası: 3. bölümdeki tablonun 2. adımı, thread’lerin Redis’i değil, havuzu beklemesiyle de başlayabilir.

Bu adım atlanırsa geri kalan hiçbir şey çalışmaz. Devre kesici (circuit breaker) de, kuyruk sınırı da, zaman aşımı olmadan devreye giremez.

Değeri nasıl seçersin? Havadan değil, ölçümden: o çağrının gerçek p99’unu al, ~1,5 ile çarp. Redis 120 ms’de p99 yapıyorsa 200 ms; köprü 500 ms’de yapıyorsa 800 ms. İkinci kural: çağıranın timeout’undan küçük olmalı. İstemci gateway’den 1 saniyede vazgeçiyorsa gateway’in Redis + köprü + DB bütçesi toplamda 1 saniyenin altında kalmalı; yoksa gateway, artık kimsenin beklemediği bir cevap için çalışır. Bunun devamı deadline propagation: istemci 800 ms’de vazgeçtiyse alt katman devam etmesin. Kalan süreyi header’la aşağı geçir (X-Remaining-Ms: 450; gRPC’nin grpc-timeout’u da tam bunu taşır); alt katman süre dolmuşsa hiç başlamasın. Header’a mutlak zaman damgası koyma: “deadline 09:00:01.800” demek, iki makinenin saatinin aynı olduğunu varsaymaktır; makineler arası 200 ms’lik bir saat kayması 800 ms’lik bütçenin dörtte biridir ve yönüne göre ya canlı isteği öldürür ya da ölü isteği yaşatır. Kalan süre gönder, her katman kendi saatiyle geri saysın. Aksi hâlde yük altında en pahalı işi, cevabı çöpe gidecek isteklere yaparsın.

4. adımı kesen şey bu. Sınırlı kuyruk (bounded queue) dolduğunda istek reddedilir — kötü, ama süreç ayakta kalır. Sınırsız kuyruk, bellek bitene kadar kabul eder ve hepsini birden kaybeder.

“Kuyruk” tek bir şey değil; bir gateway’de en az beş tane var ve önce hangisinin sınırsız olduğunu bulman gerekiyor:

• Accept kuyruğu. Tomcat’te acceptCount (varsayılan 100) ve maxConnections (NIO’da 8.192). Zaten sınırlı; dolunca yeni bağlantı reddedilir.
• Thread pool’un iş kuyruğu. Tomcat’in kendi havuzu sınırlı. Ama senin Executors.newFixedThreadPool(n) ile açtığın her havuzun arkasında sınırsız bir LinkedBlockingQueue var; newCachedThreadPool() ise thread sayısını sınırlamaz. Java’nın en klasik sınırsız kuyruğu bu.
• Uygulama içi async kuyruk. Emirleri köprüye taşıyan, tick’leri işleyen kendi BlockingQueue’n. Kapasite verilmemişse sınırsız.
• Netty / soket çıkış tamponu. Yavaş okuyan istemciye yazmaya devam edersen outbound buffer büyür; WRITE_BUFFER_WATER_MARK ve isWritable() bunun için.
• İstemci tarafı tampon. Terminalde biriken abonelik verisi; senin sunucunu değil istemciyi öldürür, ama kopunca 1. bölümün reconnect çığına döner.

Tablodaki 4. adımın (bellek doluyor) kaynağı, accept kuyruğu zaten sınırlı olduğu için, büyük ihtimalle ikinci ya da üçüncü madde: senin kendi havuzun ya da kendi kuyruğun. Düzeltmesi üç satır:

// YANLIS: Executors.newFixedThreadPool(50) -> arkasinda SINIRSIZ LinkedBlockingQueue
ExecutorService havuz = new ThreadPoolExecutor(
    50, 50, 0L, TimeUnit.MILLISECONDS,
    new ArrayBlockingQueue<>(1_000),                       // sinir: 1000 bekleyen is
    new ThreadPoolExecutor.AbortPolicy());                   // dolunca RejectedExecutionException -> 503

// CallerRunsPolicy DEGIL: isi kabul eden thread'de (Tomcat worker, Netty event loop) calistirir,
// o thread bloke olur, kabul de durur; "zarif backpressure" gibi gorunur, kaskadi hizlandirir.

// Olcut: kuyrukta bekleme suresi, doluluk degil. Doluluk gecikmeli bir sinyal;
// 5 sn beklemis fiyat istegi zaten degersiz, isleyip cevap donmenin anlami yok.
// CoDel'den esinlenmis basitlestirme: gercek CoDel ANLIK degere degil, bir interval (100 ms)
// boyunca bekleme suresinin MINIMUMUNUN hedefi asip asmadigina bakar. Kisa bir patlamada minimum
// dusuk kalir, atma olmaz; surekli birikimde minimum da yukselir, o zaman atar.
if (kuyruk.sonPencereMinBeklemeMs(100) > 500 && !istek.kritikMi()) {
    // Retry-After SABIT olursa reddedilen herkes t+2'de ayni anda doner: 1. bolumdeki cig.
    int retryAfter = 2 + ThreadLocalRandom.current().nextInt(4);    // 2-5 sn, jitter'li
    return Response.status(503)
                   .header("Retry-After", String.valueOf(retryAfter))   // HEADER, govde degil
                   .build();
}

Fiyat sorgusunu reddedip emri kabul etmek, ikisini birden yavaşça kaybetmekten iyidir. Yükü atmak bir başarısızlık değil, bir öncelik kararı. İki ayrıntı: bu yazının ilk hâlinde Retry-After: 2 sabitti — yani reddedilen bütün istemcileri iki saniye sonra aynı saniyede geri çağırıyordu; 1. bölümde anlattığım çığı 3. bölümde kendim üretiyordum. Ve kuyruk doluluğu geç konuşan bir ölçüt: %80 dolduğunda kuyruğun başındaki istek çoktan saniyelerdir bekliyor. Kuyrukta bekleme süresi hem daha erken hem daha dürüst bir sinyal — ama anlık değeri değil, pencere içi minimumu: bu yazının ilk hâlinde kural “baştaki istek 500 ms’den yaşlıysa” diyordu ve o hâliyle her 600 ms’lik tek patlamada 503 basıyordu. CoDel’in bütün numarası tam olarak bunu yapmamak: 100 ms boyunca en iyi istek bile 500 ms beklemişse birikim gerçektir, o zaman at.

Bunun doğal devamı iki kural daha. Aşırı yükte LIFO. Kuyruk birikmişken FIFO, en eski isteği önce işler — yani istemcinin çoktan vazgeçtiği isteği. %100 CPU ile %0 faydalı iş. Yük altında sondan almak (LIFO) en azından hâlâ bekleyen birine cevap verir. Ölü isteği kuyruktan almadan at. İstek deadline’ını taşıyorsa (yukarıdaki deadline propagation) ve süresi dolmuşsa, işlemeye başlamadan düşür; cevabı kimse okumayacak. İkisi de kapasite eklemeden kurtarır; çünkü kapasite hep vardı, sadece çöpe gidiyordu.

Bir eksik daha: yukarıdaki kodda tek ayrım kritikMi(). Yük atma kime ait olduğuna bakmıyor; tek bir istemcinin retry fırtınası (bozuk bir bot, döngüye girmiş bir entegrasyon) bütün kuyruğu yer ve reddedilen, diğer 5.000 müşteri olur. Load shedding’in gerçek hayattaki eşlikçisi müşteri başına adalet: per-tenant rate limit (kimse saniyede N isteğin üstüne çıkamaz) ya da weighted fair queuing (kuyruk dolunca en çok tüketen önce atılır). Kuyruk ne kadar dolu sorusunun yanına “kim doldurdu” sorusu gelmeli.

Devre kesiciden önce gelen savunma bu; 3. bölümdeki sıranın dördüncüsü. Devre açılana kadar (minimumNumberOfCalls=20 + pencere) 200 thread’lik ortak havuz zaten tükenmiş olur; yedi saniyelik hikâye tam olarak o pencerede geçti. Gemideki su geçirmez bölmeler gibi: her köprüye kendi havuzu ya da semaforu, biri dolunca diğerleri çalışmaya devam eder.

// Kopru basina ayri sinir: tek bir kopru 200 thread'in tamamini alamaz
BulkheadConfig bh = BulkheadConfig.custom()
    .maxConcurrentCalls(25)                       // bu kopruye ayni anda en fazla 25 cagri
    .maxWaitDuration(Duration.ofMillis(50))       // yer yoksa 50 ms icinde reddet, bekletme
    .build();
Bulkhead kopruA = Bulkhead.of("mt5-kopru-A", bh);

Supplier<Emir> korunan = Bulkhead.decorateSupplier(kopruA, () -> kopruAGonder(emir));

Köprü A asılı kalınca en fazla 25 thread orada takılır; 175’i B, C ve D için serbest kalır. Devre kesici sonra gelir ve o 25’i de kurtarır. Aynı kural devre kesici için de geçerli: bağımlılık başına bir breaker. Bütün köprüleri tek bir global breaker’ın arkasına koyarsan köprü A’nın hataları B, C ve D’ye giden yolu da kapatır; bu hikâyede global breaker hiçbir işe yaramaz.

maxConcurrentCalls(25) bir tahmin; köprünün bugünkü kapasitesine göre doğru, yarın yavaşladığında yanlış. Bunun bir sonraki adımı adaptif eşzamanlılık sınırı: sınırı elle koymak yerine gecikmeden türetmek. Netflix’in concurrency-limits kütüphanesi (Gradient, Vegas algoritmaları; TCP’nin tıkanıklık kontrolüyle aynı fikir) p50 gecikme yükselmeye başlayınca sınırı düşürür, düşünce yükseltir; Envoy’da aynı şey adaptive_concurrency filtresi. Sabit 25 ile başla, ama sınırın yanına gecikme grafiğini koy: 25’e hiç ulaşmadan p99 ikiye katlanıyorsa sınır çok yüksek demektir.

// MT5 koprusu (senkron HttpClient.send) icin breaker
CircuitBreakerConfig.custom()
    .slidingWindowType(SlidingWindowType.TIME_BASED)   // ← COUNT_BASED dusuk trafikte saatler onceki cagrilari tutar
    .slidingWindowSize(60)                              // son 60 saniye
    .minimumNumberOfCalls(20)                           // ← 20 cagri olmadan karar verme
    .failureRateThreshold(50)                           // %50 hata -> ac
    .slowCallDurationThreshold(Duration.ofMillis(400))  // ← timeout'un (800 ms) ALTINDA olmali, ~%50'si
    .slowCallRateThreshold(50)                          // ← YAVAS cagri da hata sayilir
    .waitDurationInOpenState(Duration.ofSeconds(10))
    .automaticTransitionFromOpenToHalfOpenEnabled(true)  // ← varsayilan false: gecis ancak bir CAGRI gelince olur
    .permittedNumberOfCallsInHalfOpenState(5)
    .recordExceptions(IOException.class)                // ← sadece altyapi hatasi sayilir; HttpTimeoutException IOException'dan turer
    .ignoreExceptions(YetersizTeminatException.class,   // ← is hatasi devreyi ACMAZ
                      GecersizSembolException.class)    //   (ikisinden biri yeter, asagida)
    .build();

// AYNI config'i Redis yoluna KOPYALAMA: Jedis IOException atmaz.
// JedisConnectionException -> JedisException -> RuntimeException. Lettuce'ta da RedisConnectionException
// ve RedisCommandTimeoutException RuntimeException'dir. Redis breaker'inda:
//   .recordExceptions(JedisConnectionException.class)      // baglanti + socket timeout ikisi de buradan gelir

• minimumNumberOfCalls olmazsa sabah ilk iki çağrı hata alınca devre açılır ve servis hiç denenmemiş olur.
• slowCallRateThreshold çok önemli. Gri arıza (gray failure) tam burada yakalanıyor: köprü hata dönmüyor, sadece 5 saniyede dönüyor. Yavaş çağrıyı hata saymazsan devre hiç açılmaz. Eşik timeout’un altında olmalı: bu yazının ilk hâlinde ikisi de 800 ms’ydi ve o hâliyle “yavaş ama başarılı” diye bir kategori kalmıyordu — 800 ms’ye ulaşan her çağrı zaten timeout olarak failure sayılıyor, mekanizma ölü doğuyordu. Pratik oran timeout’un %50–60’ı: 800 ms timeout için 400–500 ms.
• recordExceptions / ignoreExceptions pratikte en çok yakan ayar. Varsayılan: her exception hata. Sabah bir müşteri grubu “yetersiz teminat” alıyorsa — ki bu köprünün doğru cevabı — devre sapasağlam köprüye karşı açılır ve herkesin emri reddedilir. İş hatası ile altyapı hatasını ayır; devre yalnızca ikincisine baksın. Yukarıdaki örnekte ikisinin birden olması şart değil: recordExceptions verdiğin anda listede olmayan hiçbir exception failure sayılmaz, ignoreExceptions onun da üstünde önceliklidir. Pratikte recordExceptions’ı daraltmak daha güvenli, çünkü yarın eklenen yeni bir iş exception’ı varsayılan olarak devreyi açmaz; ignoreExceptions ile gidersen her yeni iş hatasını listeye eklemeyi hatırlaman gerekir. Daraltmanın kendi tuzağı da var, bu maddenin en sinsi hâli: istemci kütüphanesinin exception hiyerarşisini kontrol et. Bu yazının ilk hâlinde listede IOException ve java.util.concurrent.TimeoutException vardı. İkincisi senkron HttpClient.send()’den hiç gelmez; o HttpTimeoutException atar, o da IOException’dır. TimeoutException yalnızca sendAsync / CompletableFuture yolunda görünür; senkron kod gösterip async exception’ı kaydediyordum, zararsız ama yanlış. Zararlısı şu: aynı listeyi Redis breaker’ına kopyalarsan devre hiç açılmaz, çünkü Jedis IOException atmaz; bağlantı kopması da, socket timeout da JedisConnectionException’dır ve o bir RuntimeException. Listede olmadığı için failure sayılmaz, Redis günlerce yanıt vermese bile breaker kapalı kalır. Her bağımlılık için bir kez yap: istemcinin gerçekte hangi sınıfı attığını testte tetikle, o sınıfı yaz.
• slidingWindowType unutulur. Sayı tabanlı pencere (son 100 çağrı) düşük trafikte saatler önceki çağrıları hesapta tutar; gece 02:00’deki 3 hata sabah 09:00’da hâlâ oranın içindedir. Zaman tabanlı pencere (son 60 sn) “şu an” sorusuna cevap verir.
• automaticTransitionFromOpenToHalfOpenEnabled varsayılan olarak kapalı. Kapalıyken OPEN→HALF_OPEN geçişi waitDurationInOpenState dolunca değil, dolduktan sonra ilk çağrı geldiğinde olur. Trafiği kesip beklediğin kurtarma senaryosunda (aşağıda) devre panoda sonsuza kadar OPEN görünür; “devreler toparlandı mı” sorusuna trafik açmadan cevap alamazsın. true yapınca geçiş zamanlayıcıyla kendiliğinden olur, panoda HALF_OPEN’ı görürsün ve açtığın ilk %10 trafiğin ilk 5 çağrısı deneme olarak geçer. Bedeli breaker başına bir zamanlayıcı; yüzlerce breaker’ın yoksa önemsiz.

Bu yazının ilk hâlinde retry’ın yeri hiç geçmiyordu; oysa sarma sırası yanlışsa devre kesici de, bulkhead da işe yaramaz. Resilience4j’nin önerdiği sıra dıştan içe Retry(CircuitBreaker(RateLimiter(TimeLimiter(Bulkhead(çağrı))))):

// Decorators'ta ilk yazilan EN ICTE kalir; retry en son yazilir, en DISTA durur
Supplier<Emir> s = Decorators.ofSupplier(() -> kopruAGonder(emir))   // timeout HttpRequest'in kendisinde (800 ms)
    .withBulkhead(kopruA)          // 1) yer var mi? yoksa 50 ms icinde reddet
    .withCircuitBreaker(cbA)       // 2) devre acik mi? aciksa CallNotPermittedException, kopru hic aranmaz
    .withRetry(retryA)             // 3) EN DISTA: breaker gecirdi ve altyapi hatasi geldiyse bir daha dene
    .decorate();

RetryConfig retryCfg = RetryConfig.custom()
    .maxAttempts(2)                                   // toplam 2 deneme, 3 degil
    .intervalFunction(IntervalFunction.ofExponentialRandomBackoff(100, 2.0))   // jitter'li
    .retryExceptions(IOException.class)               // senkron HttpClient: timeout da IOException (HttpTimeoutException)
    // Breaker'daki kural burada da gecerli: liste verildigi an CallNotPermittedException, BulkheadFullException
    // ve is hatalari ZATEN denenmez; ayrica ignoreExceptions yazmaya gerek yok. Varsayilan (liste yok) ise
    // HER exception'i tekrar dener -- devre acikken bile.
    .build();

Bu inşa sırası; çalışma anında zincir dıştan içe, yani 3. bölümdeki omurganın tersinden işler: retry → breaker → bulkhead → çağrı. İkisi de doğru, ikisini yan yana okurken karıştırma.

Sıra neden bu? Retry’ı breaker’ın içine koyarsan her deneme breaker’a ayrı bir failure olarak yazılır: 3 deneme = 3 hata, devre üç kat hızlı açılır. Retry’ı breaker’ın dışına koyup retryExceptions listesini boş bırakırsan varsayılan her exception’ı dener, CallNotPermittedException dahil: devre açıkken bile retry backoff’u bekler; çağrı hiç yapılmıyor ama thread bekliyor. İkinci kural daha az bilinir ve daha pahalıdır: retry katmanlar arasında çarpımsaldır. İstemci 3 deneme, gateway 3 deneme, köprü istemcisi 3 deneme: kaynağa giden yük 3 değil, 3 × 3 × 3 = 27 kat. 1. bölümdeki retry budget bunu tek katmanda %10’a bağlar, ama üç katmanın her biri kendi bütçesiyle retry yapıyorsa çarpım yine oradadır. Kural: yalnızca en dış katman retry yapar; ara katmanlar hatayı olduğu gibi yukarı geçirir.

Bir de sıradaki TimeLimiter’ın ne işe yaradığı: timeout kabul etmeyen kütüphane için var. “Timeout olmadan hiçbir şey çalışmaz” tezinin kaçış kapısı bu. Sağlayıcının verdiği eski SDK gonder()’e süre parametresi almıyorsa, çağrıyı ayrı bir havuza atıp dışarıdan kesersin:

// SDK timeout bilmiyor: cagri ayri thread havuzunda, sure disaridan
ThreadPoolBulkhead tpb = ThreadPoolBulkhead.of("kopru-B", ThreadPoolBulkheadConfig.custom()
    .maxThreadPoolSize(25).queueCapacity(1).build());      // 25 thread, kuyruk fiilen yok (en az 1 olmak zorunda): yer yoksa reddet
TimeLimiter tl = TimeLimiter.of(Duration.ofMillis(800));

CompletableFuture<Emir> f = Decorators.ofSupplier(() -> eskiSdk.gonder(emir))
    .withThreadPoolBulkhead(tpb)              // 1) ayri havuz
    .withTimeLimiter(tl, zamanlayici)         // 2) 800 ms'de future'i kes -> java.util.concurrent.TimeoutException
    .withCircuitBreaker(cbB)                  // 3) bu yolda breaker'a TimeoutException.class KAYDEDILIR
    .withRetry(retryB, zamanlayici)           // 4) en dista
    .get().toCompletableFuture();

İki dürüst not. TimeLimiter future’ı keser, thread’i değil: SDK interrupt’a bakmıyorsa kesilen çağrı o thread’i cevap gelene kadar tutmaya devam eder. Havuzun 25 ile sınırlı olmasının sebebi tam bu; en fazla 25 zombi, sonra red. Ve yukarıda “senkron koddan TimeoutException gelmez” dedim; bu yol asenkron, burada gelir, breaker’ın record listesi de ona göre yazılır. Hangi yoldaysan o yolun exception’ı.

1,8 saniyelik GC duraklamasını health check’te yakalamak teşhis; fiyat motorunda asıl iş o duraklamanın olmaması. Sıra önemli, ucuzdan pahalıya:

• Ölç. -Xlog:gc* ile duraklama nedenini oku: humongous allocation, full GC, promotion failure? Tedavi nedene bağlı; ölçmeden collector değiştirmek tahmin.
• Allocation rate’i düşür. Tick başına yeni nesne üretme: tick objelerini yeniden kullan, kutulamayı (boxing) kes, primitive koleksiyon kullan, string birleştirmeyi sıcak yoldan çıkar. En etkili adım genelde bu ve collector’dan bağımsız.
• Collector’ı seç. G1’in duraklaması heap’le büyür; ZGC (generational sürümü JDK 21’de -XX:+ZGenerational ile, JDK 23’ten itibaren varsayılan) ve Shenandoah duraklamayı heap boyutundan bağımsız olarak milisaniye mertebesinde tutar, bedeli biraz CPU ve throughput. Fiyat motoru için doğru takas bu; batch işi için değil.
• Büyük veriyi heap dışına al. Sembol tarihçesi, order book snapshot’ı gibi büyük ve uzun ömürlü yapılar off-heap (Chronicle, Agrona, doğrudan ByteBuffer) ya da ayrı bir süreçte dursun; collector’ın tarayacağı canlı nesne azalsın.