Temporal ile Dayanıklı Workflow Orkestrasyonu

Dağıtık sistemlerde en zor problemlerden biri "uzun süren iş" yönetimidir. Sipariş alırsın, ödeme doğrularsın, stok düşersin, e-posta gönderirsin, kargo sistemine bildirirsin. Bu adımların biri başarısız olduğunda ne olacak? İş yarım kalırsa nasıl devam edecek? Servis restart olursa süreç nereden sürecek?

Temporal bu problemi durable workflow modeliyle çözer. Mantık basittir: iş akışını kodla ifade edersin, durum geçişlerini Temporal saklar, hata olduğunda sistem güvenli şekilde devam eder. Böylece "retry, timeout, idempotency, saga compensation" gibi konuları her mikroserviste tekrar tekrar yazmak zorunda kalmazsın.

Orkestrasyon Modeli

Client -> Start Workflow
           |
           v
    +--------------------+
    | Temporal Server    |
    | event history      |
    +---------+----------+
              |
              v
        +-----------+
        | Worker    |---- Activity: Payment
        +-----------+---- Activity: Inventory
              |          Activity: Notification
              v
        Workflow state persisted

Workflow kodu işin sırasını tanımlar; Activity fonksiyonları dış sistemlerle konuşur. Sunucu her adımın event history'sini tuttuğu için worker çökse bile iş kaldığı yerden devam eder.

Neden Cron + Queue Değil?

Çok ekip başlangıçta cron + message queue + DB tablosu kombinasyonu kurar. Kısa vadede çalışır, orta vadede bakım maliyeti büyür:

• Hangi iş hangi adımda kaldı takip zorlaşır.
• Retry politikaları servisler arasında tutarsız olur.
• Timeout ve compensation akışı manuel yazılır.
• Operasyon ekibi için gözlemlenebilirlik düşer.

Temporal bu parçaları platform seviyesine çıkarır: timeout, retry, schedule, signal, query, versioning gibi yetenekler hazır gelir.

Kritik Tasarım İlkeleri

1) Workflow Deterministic Olmalı

Workflow kodu aynı history ile tekrar oynatıldığında aynı kararı vermelidir. Bu yüzden rastgelelik, doğrudan saat okuma veya dış API çağrısı workflow içinde değil activity içinde yapılmalıdır.

2) Activity'ler Idempotent Tasarlanmalı

Retry olduğunda aynı activity birden fazla kez çalışabilir. Ödeme çekimi, e-posta gönderimi gibi işlemler için idempotency key zorunludur.

3) Timeout ve Retry Ayrı Düşünülmeli

• Kısa ağ kopmaları için retry iyidir.
• Uzun süren kilitlenmelerde timeout gerekir.
• Her activity için aynı policy kopyalamak yerine iş riskine göre ayar yapılmalıdır.

Örnek Sipariş Akışı

[OrderWorkflow]
    |
    +--> ReserveInventory
    |       fail -> cancel workflow
    |
    +--> ChargePayment
    |       fail -> ReleaseInventory (compensation)
    |
    +--> CreateShipment
    |       fail -> RefundPayment + ReleaseInventory
    |
    +--> SendConfirmationMail
            fail -> retry (non-critical)

Bu yapıda her kritik adımın geri alma (compensation) karşılığı tanımlanır. Böylece iş süreçleri "eventual consistency" içinde kontrol altında kalır.

Operasyonel Kazanımlar

Temporal kullanımında ekiplerin en çok fayda gördüğü alanlar:

• Gözlemlenebilirlik: Her workflow instance'ının adım adım geçmişi.
• Daha az custom kod: Retry queue, scheduler, state machine kodu azalır.
• Daha hızlı incident çözümü: "Nerede kaldı?" sorusu dakikalar içinde yanıtlanır.
• Güvenli deploy: Workflow versioning ile kırılmasız geçiş mümkün.

Ne Zaman Uygun Değil?

Temporal her sorunun cevabı değildir. Çok kısa, tek adımlı ve düşük riskli işlemler için standart request-response veya basit queue yeterli olabilir. Platform ekibinin öğrenme eğrisi ve operasyonel sahipliği değerlendirilmeden geçiş yapmak doğru olmaz.

Başlangıç İçin Yol Haritası

1. İlk aday olarak çok adımlı ve hata yönetimi zor bir süreci seç.
2. Mevcut retry/timeout kurallarını çıkar, workflow'a taşı.
3. Idempotency standartlarını belirle.
4. Dashboard + alarm kur (workflow timeout, retry spike).
5. Küçük bir pilot sonrası kademeli genişlet.

Sonuç

Dağıtık sistemlerde dayanıklılık çoğu zaman iş mantığından çok "hata durumunu iyi modelleme" becerisidir. Temporal, bu modellemeyi kodlanabilir ve işletilebilir hale getirir. Uzun süren süreçlerde güvenilirlik, izlenebilirlik ve bakım kolaylığı arıyorsan, özellikle ödeme/sipariş/abonelik gibi kritik alanlarda güçlü bir kaldıraç sağlar. Doğru sınırlar içinde kullanıldığında ekiplerin hem geliştirme hızını hem operasyonel güvenini belirgin biçimde artırır.