Bir agentic sistem sevk eden her ekip, genellikle üçüncü ay civarında aynı soruyu sorar: "Temporal / Inngest / Restate'e ihtiyacımız var mı, yoksa sadece retry mi ekleyelim?"
Cevap neredeyse her zaman "durable orkestratöre ihtiyacınız var, ama nedeni 'retry' değil."
Retry'ler aslında neyi çözer
Retry'ler, geçici bir başarısızlığın çağrıyı yapan aynı süreç tarafından gözlemlendiği zaman doğru araçtır. Network kesintisi, rate-limit yanıtı, kararsız bir downstream — çağrıyı yapan başarısız sonucu elinde tutar, ne yapmaya çalıştığını bilir ve sadece tekrar deneyebilir.
Bunun için gerekli olanlar: exponential backoff'lu bir retry politikası, max attempts limiti ve receiver tarafında idempotency. Bu bir kütüphanedir, sistem değil. p-retry, tenacity, tokio-retry — birini seçin ve devam edin.
Durable execution aslında neyi çözer
Durable execution, sürecin kendisinin adımlar arasında ölebileceği zaman doğru araçtır. Crash, deploy, k8s'in pod'u evict etmesi, request timeout'unuzu aşan 30 dakikalık bir LLM çağrısı — soru "tekrar deneyebilir miyiz" değil, "ışıklar söndüğünde neredeydik ve halihazırda başarılı olan kısımları tekrar yapmadan nasıl devam ederiz?"
Bu temelde farklı bir problemdir. Gerektirdikleri:
- Kalıcı step state — hangi adımların tamamlandığının, sonuçlarıyla birlikte tutulduğu bir log.
- Replayable history — süreç devam ettiğinde, log'u dolaşır, biten adımları atlar ve ilk bitmeyen adımdan devam eder.
- Deterministic step sınırları — kod, orkestratörün adımları replay'ler arasında belirsiz olmayan şekilde tanımlayabileceği şekilde yapılandırılmış olmalı.
Bunu sıfırdan yazabilirsiniz. İnsanlar yazıyor. Temporal'ın daha kötü bir versiyonunu inşa ettiğinizi fark etmeden önce altı aylık race condition debug'ı.
Asıl karar
Agentic sisteminizde:
- Tek tek birkaç saniyeden uzun süren tool call'lar varsa,
- ~3 sıralı adımdan fazla içeren workflow'lar varsa,
- Ortada bir yerde handoff veya human-in-the-loop varsa,
- Bir deploy restart'ının kullanıcıya görünür bir başarısızlığa neden olmasını tolere edemeyen SLA'ler varsa,
…durable bir orkestratöre ihtiyacınız var. "Hoş olur diye isteyebilirsiniz" değil. İhtiyacınız var ve sonradan eklemek, başlangıçta eklemekten çok daha pahalı olacak.
Sisteminiz kısa, senkron ve stateless ise (bir prompt, bir yanıt, 5 saniyede biter), retry'ler yeterlidir. Aşırı mühendislik yapmayın.
Sevk ettiğimiz
Pratikte default'umuz Temporal veya Restate (dil stack'ine bağlı olarak), workflow kodu her LLM call'u, tool invocation'ı ve onayın ayrı bir adım olduğu şekilde yapılandırılmış. Maliyeti biraz öğrenme eğrisi ve işletilecek bir runtime. Faydası ise "bu süreç workflow ortasında crash olduğunda ne olur" sorusunun, her yeni özellik için cevaplamamız gereken bir soru olmaktan çıkması — orkestratör buna bir kez cevap verir.
Retry'ler "bu call başarısız oldu"yu çözer. Durable execution "bu workflow, onu çalıştıran şeyin başarısızlıkları boyunca hayatta kalmalı"yı çözer. Bunlar alternatif değildir — production sistemlerin çoğu her ikisine de ihtiyaç duyar ve insanların hafife aldığı ikincisidir.