Failure Modes

1. Thundering herd: herkes aynı anda

Piyasa 09:00’da açılıyor. O saniyede olan şeyler:

• Bütün gateway’ler sembol listesini Redis’ten çekiyor.
• Bütün köprüler sağlayıcılara bağlanıyor.
• Bütün zamanlanmış işler 0 0 9 * * * ifadesiyle tetikleniyor.
• Gece boyunca duran istemciler yeniden bağlanıyor.

Hiçbiri tek başına ağır değil. Ama hepsi aynı saniyede. Sistem günün geri kalanında rahat rahat kaldırdığı yükü, o bir saniyede kaldıramıyor.

// 1) Zamanlanmis is: sabit saniye yerine 0-30 sn kaydir
long kaydir = ThreadLocalRandom.current().nextLong(30_000);
zamanlayici.schedule(is, acilisZamani + kaydir);

// 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
int sira = podIndexiniOku();            // StatefulSet ordinal ya da hash
Thread.sleep(sira * 500L);              // 0, 500, 1000, 1500 ms...

Üçünün toplam maliyeti on satır. Bizde açılış anındaki Redis tepe kullanımı %100’den %40’a düştü; hiçbir şeyin kapasitesini artırmadan.

2. Cache stampede: aynı anda 200 kez hesaplanan spread

Çığ etkisinin (thundering herd) özel ve çok yaygın bir hali. symbol:EURUSD:spread anahtarının süresi doluyor. Tam o anda 200 gateway aynı anda okuyor, 200’ü de “yok” cevabı alıyor ve 200’ü birden hesaplamaya başlıyor.

Hesaplama pahalı değil — ama 200 katı pahalı. Ve hesap bitene kadar süre yine dolmuş oluyor, döngü kendini besliyor.

Üç çözüm

deger = redis.get(anahtar);
if (deger != null) return deger;

// Sadece bir tanesi kilidi alsin
if (redis.set(anahtar + ":kilit", ben, "NX", "PX", 5000)) {
    deger = pahaliHesapla();
    redis.setex(anahtar, ttlSapmali(), deger);
    redis.del(anahtar + ":kilit");
    return deger;
} else {
    // Digerleri: eski degeri kullan (ayri, uzun omurlu anahtar)
    return redis.get(anahtar + ":eski");
}

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

long kalan = bitis - simdi();
double esik = -hesapSuresi * BETA * Math.log(Math.random());   // BETA ~ 1.0

if (kalan < esik) {
    deger = pahaliHesapla();      // erken, KENDILIGINDEN, tek basina
    kaydet(deger);
}
return deger;

3. Cascade failure: yavaşlığın bulaşması

Şimdi asıl olay. Baştaki hikâyenin devamı şöyle işledi:

Dikkat: 1. adımda Redis çökmedi, sadece yavaşladı. Çökseydi gateway’ler anında hata alıp hızlıca cevap dönecekti. Yavaşlama daha kötü, çünkü herkesi bekletiyor.

Üç savunma, sırayla

// Varsayilan zaman asimi genelde YOK ya da 30+ saniye.
// Trade tarafinda 30 saniye = sonsuz demek.
jedis.setTimeout(200);              // Redis: 200 ms
httpClient.timeout(Duration.ofMillis(800));   // MT5 koprusu
db.setQueryTimeout(3);              // saniye

// Kuyruk %80 doluysa, kritik olmayan isteklere hemen 503 don
if (kuyruk.doluluk() > 0.8 && !istek.kritikMi()) {
    return hata(503, "Retry-After: 2");
}

4. Circuit breaker: yanıt vermeyene istek göndermeyi bırak

Somut olay: MT5 köprüsü yanıt vermiyor. Her emir 30 saniye zaman aşımına kadar bir iş parçacığını tutuyor. Havuzda 200 parçacık var. Yedi saniyede havuz tükeniyor ve gateway artık sağlıklı köprülere de emir gönderemiyor.

Yani bir köprünün arızası, bütün emir akışını durdurdu.

CircuitBreakerConfig.custom()
    .slidingWindowSize(100)              // son 100 cagri
    .minimumNumberOfCalls(20)            // ← 20 cagri olmadan karar verme
    .failureRateThreshold(50)            // %50 hata -> ac
    .slowCallDurationThreshold(Duration.ofMillis(800))
    .slowCallRateThreshold(50)           // ← YAVAS cagri da hata sayilir
    .waitDurationInOpenState(Duration.ofSeconds(10))
    .permittedNumberOfCallsInHalfOpenState(5)
    .build();

5. Gray failure: ayakta ama ölü

En zor teşhis edilen arıza sınıfı. Streaming-engine ayakta, /health uç noktası 200 OK dönüyor, süreç çalışıyor. Ama uzun bir çöp toplama duraklaması yüzünden gerçek işi yapamıyor: fiyat işlemiyor, elindeki 4 saniyelik eski kotasyonu yayınlıyor.

Yük dengeleyici sağlıklı görüyor ve trafik göndermeye devam ediyor. Sonuç: emirlerin dörtte biri eski fiyattan açılıyor.

GET /health
→ 200 {"status":"UP"}

// Kodu:
return ok();      // ← surec ayakta, o kadar

GET /ready
{
  "son_tick_yasi_ms": 4200,     // ← 4 saniyedir tick islemedi
  "kuyruk_derinligi": 48000,
  "gc_duraklama_p99_ms": 1800,
  "status": "DEGRADED"
}

// Kural: son_tick_yasi > 1000 ise READY DEGIL

Buna ek olarak yük dengeleyici tarafında aykırı değer tespiti (outlier detection) çok işe yarıyor: “bu düğüm diğerlerinden 5 kat yavaş” kuralı, sağlık kontrolü OK dese bile o düğümü geçici olarak devre dışı bırakıyor. Gri arızaya karşı en pratik savunma bu — çünkü sağlığı mutlak değil göreli ölçüyor.

6. Failover: devraldı ama neyi kaybetti?

Redis master çöktü, Sentinel bir replikayı terfi ettirdi, sistem 8 saniyede geri geldi. Herkes rahat. Ama:

Bunun tek gerçek çözümü mimari:

1. Kritik durumun tek kopyası önbellekte olmasın. Emir ve pozisyonun doğruluk kaynağı kalıcı veritabanı olmalı; Redis hızlı bir kopya olarak durmalı. “Redis’te tutalım, hızlı” kararı failover gününe kadar doğru görünüyor.
2. Failover sonrası mutabakat otomatik olsun. Terfi tespit edilince bir iş tetiklensin: son N dakikanın emirlerini köprüden çekip yerel durumla karşılaştırsın, farkları rapor etsin. Elle yapılmaya çalışılırsa yapılmıyor.
3. Terfi anı olay olarak yazılsın. “Şu saatte failover oldu” kaydı, üç gün sonra “bu emir neden kayıp” sorusunun tek cevabı oluyor.

Hepsi bir arada: neyin ne zaman devreye girdiği

Kontrol listesi AI agent görev listesi

Sonuç

Bu altı modun ortak noktası şu: hiçbiri bir kod hatasından çıkmıyor. Hepsi doğru yazılmış parçaların, yük altında birbirini beslemesinden doğuyor. O yüzden birim testlerde görünmüyorlar; sadece kötü bir sabahta görünüyorlar.

Ve hepsinin ilacı aynı yerde toplanıyor: sınır koy. Zaman aşımına sınır, kuyruğa sınır, tekrar denemeye sınır, aynı anda başlayan işe sınır. Sınırı olmayan her şey, bir gün sınırı senin yerine belirleyecek — ve genelde bunu bellek tükendiğinde yapacak.