Entegrasyonlarda Hata Yönetimi ve Dayanıklılık: Retry, Idempotency, Timeout

Bir entegrasyon kurduğunuzda, kontrolünüz dışındaki bir dünyaya bağlanmış olursunuz. Ödeme sağlayıcısının sunucusu yavaşlayabilir, kargo firmasının API'si geçici olarak çökebilir, ağ bir anlığına kesilebilir. Bunlar istisna değil, kaçınılmaz gerçeklerdir. Deneyimli mühendislerin bir sözü vardır: "Ağ güvenilmezdir." İşte bu yüzden entegrasyonlarda asıl mesele, hataların olup olmayacağı değil, olduğunda sisteminizin nasıl davranacağıdır. Bu yazıda, entegrasyonları dayanıklı kılan temel desenleri ele alacağız.

Hata Kaçınılmazdır: Kabullenmekle Başlayın

Dayanıklı sistem tasarımının ilk adımı, hatanın normal olduğunu kabul etmektir. "Nasıl olsa çalışır" varsayımıyla yazılan kod, ilk aksaklıkta çöker ve genellikle en kötü anda, yani canlı sistemde. Sağlam bir entegrasyon, dış servisin her an bozulabileceğini varsayarak tasarlanır. Bu düşünce biçimine "başarısızlık için tasarım" (design for failure) denir.

Sorulması gereken soru "bu servis çöker mi?" değil, "bu servis çöktüğünde benim sistemim ne yapacak?" olmalıdır. İlk soruya cevap her zaman evettir.

Timeout: Sonsuza Kadar Beklemeyin

En sık atlanan ama en kritik önlem zaman aşımıdır (timeout). Bir dış servise istek gönderdiğinizde ve cevap gelmezse, varsayılan davranış çoğu zaman sonsuza kadar beklemektir. Bu son derece tehlikelidir; çünkü bekleyen her istek bir kaynak tüketir ve yavaş bir servis, sizin tüm sisteminizi kilitleyebilir.

$ch = curl_init($url);
curl_setopt($ch, CURLOPT_TIMEOUT, 10);        // yanit icin en fazla 10 sn
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 5);  // baglanti icin en fazla 5 sn
$response = curl_exec($ch);

Makul bir zaman aşımı tanımlamak, "bu servis makul sürede cevap vermiyorsa vazgeçiyorum" demektir. Böylece yavaş bir bağımlılık, tüm sisteminizi rehin almaz.

Retry: Akıllıca Yeniden Deneyin

Bazı hatalar geçicidir: anlık bir ağ kesintisi, kısa süreli bir sunucu yoğunluğu. Bu durumlarda isteği yeniden denemek mantıklıdır. Ancak yeniden deneme dikkatli yapılmalıdır; yoksa faydadan çok zarar getirir.

• Sadece geçici hataları tekrarlayın: Zaman aşımı ve 5xx sunucu hataları tekrarlanabilir; 400 gibi istemci hataları tekrarlanmamalıdır çünkü aynı sonucu verir.
• Sınırlı sayıda deneyin: Sonsuz deneme, sorunu çözmez, büyütür.
• Kademeli bekleme (exponential backoff): Her denemede bekleme süresini artırın. Hemen ve sürekli tekrar denemek, zaten zorlanan bir servisi tamamen çökertebilir.

Kademeli beklemeye biraz rastgelelik (jitter) eklemek de önemlidir; aksi halde aynı anda hata alan tüm istemciler tam olarak aynı anda tekrar dener ve servisi yeniden boğar. Bu duruma "gürleyen sürü" (thundering herd) problemi denir.

Idempotency: Aynı İşlemi İki Kez Yapmamak

Yeniden deneme güçlü bir araçtır ama tehlikeli bir yan etkisi vardır. Diyelim ki bir ödeme isteği gönderdiniz, işlem aslında başarılı oldu ama cevap size ulaşmadan bağlantı koptu. Yeniden denerseniz, müşteriden iki kez para çekme riskiyle karşılaşırsınız. İşte idempotency tam da bu felaketi önler.

Idempotency, aynı işlemin birden fazla kez çağrılmasının, tek bir kez çağrılmasıyla aynı sonucu vermesi anlamına gelir. Bunu sağlamanın yaygın yolu, her işleme benzersiz bir anahtar (idempotency key) atamaktır. Sunucu bu anahtarı görür; daha önce işlenmişse yeni bir işlem başlatmaz, önceki sonucu döner.

$key = $request['idempotency_key'];
if ($store->exists($key)) {
    return $store->getResult($key); // zaten islendi
}
$result = $payment->charge($amount);
$store->save($key, $result);
return $result;

Retry ve idempotency birbirini tamamlayan iki yarımdır. Idempotency olmadan yeniden deneme, çözdüğünden daha büyük sorunlar doğurabilir.

Devre Kesici (Circuit Breaker)

Bir dış servis tamamen çökmüşse, ona istek göndermeye devam etmek anlamsızdır; her istek zaman aşımına düşer ve kaynak harcar. Devre kesici deseni, tıpkı elektrik sigortası gibi çalışır: bir servis üst üste hata vermeye başladığında, devre "açılır" ve bir süre boyunca o servise hiç istek gönderilmez. Belirli bir süre sonra sistem, servisin toparlanıp toparlanmadığını tek bir deneme isteğiyle kontrol eder.

Bu desen, çöken bir servisin sizin sisteminizi de aşağı çekmesini önler. Başarısız isteklerle vakit ve kaynak harcamak yerine, hızlıca "bu servis şu an çalışmıyor" cevabını vererek kullanıcıya anlamlı bir mesaj gösterebilirsiniz.

Zarif Düşüş ve Kayıt Tutma

Her hata, tüm işlemi durdurmak zorunda değildir. Zarif düşüş (graceful degradation), bir parça çalışmadığında sistemin geri kalanının ayakta kalmasını sağlar. Örneğin öneri servisi çökmüşse, ürün sayfası öneriler olmadan yine de açılabilir. Ayrıca dış servislerle olan her etkileşimi kaydetmek (loglamak), bir sorun yaşandığında elinizdeki tek kanıttır; hangi isteğin ne zaman gönderildiğini ve ne cevap aldığını görmeden hata ayıklamak neredeyse imkânsızdır.

• Kritik olmayan bir servis çökerse, sistemin geri kalanı çalışmaya devam etmeli.
• Kullanıcıya teknik hata değil, anlamlı bir mesaj gösterilmeli.
• Her dış istek ve yanıt, sorun analizi için kaydedilmeli.

Berasoft Yaklaşımı

E-ticaret ve kurumsal entegrasyon projelerinde, özellikle ödeme ve kargo gibi kritik akışlarda bu dayanıklılık desenlerini standart olarak uygularız. Zaman aşımı, akıllı yeniden deneme, idempotency anahtarları ve devre kesici olmadan kurulan bir entegrasyon, ilk ciddi aksaklıkta müşteri kaybına ve veri tutarsızlığına yol açar. Sistemleriniz dış dünya çalkalansa bile ayakta kalsın istiyorsanız projenizi konuşalım.

Sonuç

Entegrasyonlarda hata bir ihtimal değil, kesinliktir. Dayanıklı bir sistem, hataları önlemeye değil, hatalar olduğunda ayakta kalmaya odaklanır. Zaman aşımı yavaş servislerin sizi kilitlemesini önler; akıllı yeniden deneme geçici sorunları aşar; idempotency tekrarlanan işlemlerin zarar vermesini engeller; devre kesici çöken bir servisin sizi de aşağı çekmesine izin vermez. Bu desenleri birlikte uyguladığınızda, kontrol edemediğiniz bir dünyaya bağlanmış olsanız bile sisteminiz sağlam, öngörülebilir ve güvenilir kalır. Gerçek mühendislik, işler yolundayken değil, ters gittiğinde kendini gösterir.