Uzun Süreli Görevler için Olay Tabanlı İş Akışları ile İstek–Yanıt API'leri

İş uygulamalarında uzun süreli süreçler neden zor

Bir süreç “uzun süreli”dir çünkü tek bir hızlı adımda bitmez. Dakikalar, saatler veya günler sürebilir; çünkü insanlara, zamana veya dış sistemlere bağlıdır. Onaylar, el değiş tokuşları ve beklemeler olan her şey bu kapsama girer.

İşte bu noktada basit istek-yanıt API mantığı yetersiz kalmaya başlar. Bir API çağrısı kısa bir değiş tokuş için tasarlanmıştır: bir istek gönder, bir cevap al, devam et. Uzun görevler daha çok bölümleri olan bir hikâye gibidir. Duraklamanız, tam olarak nerede olduğunuzu hatırlamanız ve tahmin etmeden daha sonra devam etmeniz gerekir.

Bunu günlük iş uygulamalarında görürsünüz: bir satın alma onayı için yönetici ve finans onayı gerekmesi, çalışan işe alımının belge kontrolleri beklemesi, iadelerin bir ödeme sağlayıcısına bağlı olması veya erişim taleplerinin incelenip uygulanması gerekmesi.

Takımlar uzun süren bir süreci tek bir API çağrısı gibi ele aldığında bazı öngörülebilir problemler ortaya çıkar:

• Uygulama yeniden başlatma veya deploy sonrası durumu kaybeder ve güvenli şekilde devam edemez.
• Yeniden denemeler çoğaltma yaratır: ikinci ödeme, ikinci e-posta, çift onay.
• Sahiplik belirsizleşir: sıradaki adımı istekte bulunan mı, yönetici mi yoksa bir sistem işi mi yapmalı bilinmez.
• Destek görünürlükten yoksundur ve “nerede takıldı?” sorusuna log'larda kazmadan cevap veremez.
• Bekleme mantığı (zamanlayıcılar, hatırlatmalar, son tarihler) kırılgan arkaplan script'leri olarak dağılır.

Somut bir senaryo: bir çalışan yazılım erişimi talep eder. Yönetici hemen onaylar, ama BT'nin bunu sağlamak için iki güne ihtiyacı vardır. Eğer uygulama süreç durumunu tutamıyor, hatırlatmalar gönderemiyor ve güvenli şekilde devam edemiyorsa, manuel takipler, şaşkın kullanıcılar ve ekstra işler ortaya çıkar.

İşte bu yüzden uzun süreli iş süreçlerinde olay-tabanlı iş akışları ile istek-yanıt API'leri arasındaki seçim önem kazanır.

İki zihinsel model: eşzamanlı çağrılar vs zaman içinde olaylar

En basit karşılaştırma şu soruya dayanır: iş kullanıcı beklerken mi bitiyor, yoksa kullanıcı gittikten sonra mı devam ediyor?

İstek-yanıt API tek bir değiş tokuştur: bir çağrı girer, bir cevap çıkar. Kayıt oluşturma, teklif hesaplama ya da stok kontrolü gibi hızlı ve öngörülebilir işler için uygundur. Sunucu işi yapar, başarı veya hatayı döner ve etkileşim biter.

Olay-tabanlı iş akışı ise zaman içinde bir dizi tepki gibidir. Bir şey olur (sipariş oluşturuldu, yönetici onayladı, bir zamanlayıcı süresi doldu) ve iş akışı bir sonraki adıma geçer. Bu model onaylar, beklemeler, yeniden denemeler ve hatırlatmalar içeren işler için uygundur.

Pratik fark durumdur.

İstek-yanıtta durum genellikle mevcut istek ve sunucu belleğinde, cevap gönderilene kadar yaşar. Olay-tabanlı iş akışlarında durum saklanmalı (ör. PostgreSQL gibi) ki süreç daha sonra devam edebilsin.

Hata işleme de değişir. İstek-yanıt genelde hataları bir hata döndürüp istemciden tekrar denemesini ister. İş akışları hatayı kaydeder ve koşullar düzeldiğinde güvenle yeniden deneyebilir. Ayrıca her adımı bir olay olarak kaydedip geçmişi yeniden oluşturmayı kolaylaştırabilirler.

Basit bir örnek: “Masraf raporu gönder” eşzamanlı olabilir. “Onay al, 3 gün bekle, yöneticiyi hatırla, sonra öde” ise değildir.

Onaylar: her yaklaşım insan kararlarını nasıl ele alır

Onaylar, uzun süreli işlerin somutlaştığı yerdir. Sistem adımı milisaniyeler içinde biterken, bir insan iki dakika veya iki gün içinde yanıt verebilir. Ana tasarım tercihi bu beklemeyi duraklayan bir süreç olarak mı modelleyeceğiniz yoksa daha sonra gelen yeni bir mesaj olarak mı ele alacağınızdır.

İstek-yanıt API'lerde onaylar genellikle garip bir şekle dönüşür:

• Engelleme (pratik değil)
• Polling (istemci sürekli “onaylandı mı?” sorar)
• Geri arama/webhook'lar (sunucu daha sonra sizi arar)

Bunların hepsi çalışabilir ama “insan zamanı” ile “API zamanı” arasını bağlamak için ekstra tesisat ekler.

Olaylarla onay bir hikâye gibi okunur. Uygulama “ExpenseSubmitted” gibi bir şey kaydeder, sonra daha sonra “ExpenseApproved” veya “ExpenseRejected” alır. İş akışı motoru (veya kendi durum makineniz) bir sonraki olay gelene kadar kaydı ilerletmez. Bu, çoğu insanın iş adımlarını düşündüğü sırayla uyumludur: gönder, incele, karar ver.

Birden çok onaylayıcı ve tırmanma kurallarıyla karmaşıklık hızla görünür hale gelir. Hem bir yönetici hem de finans onayı gerekebilir, ama kıdemli bir yönetici üstüne yazma (override) yapabilir. Bu kuralları açıkça modellemezseniz süreç hem düşünmesi hem denetlemesi zor hale gelir.

Ölçeklenen basit bir onay modeli

Pratik bir desen, tek bir “talep” kaydı tutmak ve kararları ayrı saklamaktır. Bu sayede birçok onaylayıcıyı destekleyebilir ve temel mantığı yeniden yazmanız gerekmez.

Birkaç birinci sınıf veri parçasını yakalayın:

• Onay talebi: ne onaylanıyor ve mevcut durumu
• Bireysel kararlar: kim karar verdi, onay/reddet, zaman damgası, gerekçe
• Gerekli onaylayıcılar: rol veya kişi, ve herhangi bir sıralama kuralı
• Sonuç kuralları: “herhangi biri”, “çoğunluk”, “hepsi gerekli”, “override mümkün”

Hangi uygulamayı seçerseniz seçin, kimin neyi ne zaman ve neden onayladığını veri olarak saklayın; log satırı olarak değil.

Zamanlayıcılar ve bekleme: hatırlatmalar, son tarihler ve tırmanmalar

Bekleme uzun görevleri karışık hale getiren yerdir. İnsanlar öğle yemeğine çıkar, takvimler dolar ve “geri döneceğiz” kısa zamanda “şimdi kim sahip?” haline gelir. Bu, olay-tabanlı iş akışları ile istek-yanıt API'leri arasındaki en açık farklardan biridir.

İstek-yanıt API'lerde zaman gariptir. HTTP çağrılarının zaman aşımı vardır, bu yüzden bir isteği iki gün açık tutamazsınız. Takımlar genelde polling, veritabanını tarayan ayrı periyodik işler veya bir şey geciktiğinde manuel script'ler kullanır. Bunlar çalışabilir ama bekleme mantığı süreç dışına taşınır. Köşe durumları kolayca gözden kaçar: iş iki kez çalıştığında ne olur, ya da uyarı yollanmadan hemen önce kayıt değiştiyse?

İş akışları zamanı normal bir adım olarak ele alır. Diyebilirsiniz ki: 24 saat bekle, bir hatırlatma gönder, sonra toplam 48 saat olduğunda farklı bir onaylayıcıya tırman. Sistem durumu tutar, böylece son tarihler ayrı bir "cron + sorgular" projesinde gizlenmez.

Basit bir onay kuralı şöyle olabilir:

Masraf raporu gönderildikten sonra 1 gün bekle. Eğer durum hâlâ "Beklemede" ise yöneticiyi bildir. 2 gün sonra hâlâ beklemede ise yöneticinin liderine yeniden ata ve tırmanmayı kaydet.

Zamanlayıcı tetiklendiğinde dünyada değişiklik olmuşsa ne yapacağınız ana detaydır. İyi bir iş akışı her zaman işlem yapmadan önce güncel durumu tekrar kontrol eder:

• En son durumu yükle
• Hâlâ beklemede olduğunu doğrula
• Atanan kişinin hâlâ geçerli olduğunu doğrula (takım değişiklikleri olabilir)
• Verdiğin kararı ve nedenini kaydet

Yeniden denemeler ve çifte işlem olmadan hata kurtarma

Yeniden denemeler, bir şey sizin tam kontrolünüz dışında başarısız olduğunda yapılır: ödeme geçidi zaman aşımı verdi, e-posta sağlayıcı geçici hata döndürdü veya uygulamanız adım A'yı kaydedip B'den önce çöktü. Tehlike basittir: tekrar denerken yanlışlıkla işlemi iki kez yaparsınız.

İstek-yanıt API'lerde yaygın desen, istemcinin bir endpoint'i çağırıp beklemesi ve net bir başarı alamazsa tekrar denemesidir. Bunu güvenli kılmak için sunucu tekrarlanan çağrıları aynı niyet olarak ele almalıdır.

Pratik bir çözüm idempotency anahtarıdır: istemci pay:invoice-583:attempt-1 gibi benzersiz bir token gönderir. Sunucu o anahtar için sonucu saklar ve tekrarlar için aynı sonucu döner. Bu, çifte ücretlendirme, tekrar bilet veya çift onaylanmayı önler.

Olay-tabanlı iş akışlarında farklı bir çoğaltma riski vardır. Olaylar genellikle en az bir kez teslim edilir, bu yüzden tekrarlar ortaya çıkabilir. Tüketiciler çoğaltmayı önlemelidir: olay kimliğini (veya invoice_id + step gibi iş anahtarını) kaydedin ve tekrarları yoksayın. Bu, iş akışı orkestrasyon modellerindeki temel farklardan biridir: istek-yanıt güvenli çağrı tekrarlarını, olaylar ise güvenli mesaj tekrarlarını hedefler.

Her iki modelde de işe yarayan birkaç yeniden deneme kuralı:

• Geri çekilme kullanın (ör. 10s, 30s, 2m).
• Maksimum deneme sayısı belirleyin.
• Geçici hataları (yeniden dene) ve kalıcı hataları (hemen başarısız ol) ayırın.
• Tekrarlanan hataları "dikkat gerekiyor" durumuna yönlendirin.
• Her denemeyi kaydedin ki sonra ne olduğunu açıklayabilesiniz.

Yeniden denemeler sürecin açık bir parçası olmalı, gizli davranış değil. Böylece hatalar görünür ve düzeltilebilir olur.

Denetim izi: süreci açıklanabilir kılmak

Denetim izi sizin "neden" dosyanızdır. Birisi “Neden bu masraf reddedildi?” diye sorduğunda aylar sonra bile tahmin etmeden cevap verebilmelisiniz. Bu hem olay-tabanlı iş akışlarında hem de istek-yanıt API'lerde önemlidir ama işler farklı görünür.

Uzun süreli bir süreç için, hikâyeyi tekrar oynatmanıza izin verecek olguları kaydedin:

• Aktör: bunu kim yaptı (kullanıcı, servis veya sistem zamanlayıcısı)
• Zaman: ne zaman oldu (zaman dilimi ile)
• Girdi: o anda ne biliniyordu (tutar, satıcı, politika eşikleri, onaylar)
• Çıktı: hangi karar veya eylem gerçekleşti (onaylandı, reddedildi, ödendi, yeniden denendi)
• Kural versiyonu: hangi politika/mantık versiyonu kullanıldı

Olay-tabanlı iş akışları her adım doğal olarak "ManagerApproved" veya "PaymentFailed" gibi olaylar ürettiği için denetimi kolaylaştırabilir. Bu olayları yük ve aktörle birlikte saklarsanız temiz bir zaman çizelgesi elde edersiniz. Anahtar nokta olayları açıklayıcı tutmak ve vaka bazında sorgulanabilir bir yerde saklamaktır.

İstek-yanıt API'ler yine denetlenebilir ama hikâye genelde servisler arasında dağınıktır. Bir endpoint "onaylandı" kaydeder, diğer bir endpoint "ödeme istendi" diye kaydeder; hepsi farklı formatlarda olursa denetim dedektiflik işine dönüşür.

Basit bir çözüm ortak bir "case ID" (korelasyon ID) kullanmaktır. Her isteğe, olaya ve veritabanı kaydına bu tek tanımlayıcıyı iliştirin, örn. "EXP-2026-00173". Böylece tüm yolculuğu adımlar arasında izleyebilirsiniz.

Doğru yaklaşımı seçmek: güçlü yanlar ve ödünler

En iyi seçim, cevaba hemen ihtiyacınız olup olmadığına ya da sürecin saatler veya günler boyunca ilerlemeye devam etmesi gerekip gerekmediğine bağlıdır.

İstek-yanıt, iş kısa ve kurallar basit olduğunda iyi çalışır. Kullanıcı bir form gönderir, sunucu doğrular, veriyi kaydeder ve başarı veya hata döner. Oluşturma, güncelleme veya izin kontrolü gibi tek adımlı işler için uygundur.

Ancak "tek istek" sessizce birçok adıma dönüşmeye başladığında sorun çıkar: onay beklemek, birden çok dış sistem çağırmak, zaman aşımıyla uğraşmak veya sonraki adımların ne olacağına göre dallanmak. Ya bağlantıyı açık tutarsınız (kırılgan), ya da beklemeyi ve yeniden denemeleri arkaplan işleri olarak iter ve buna dair mantık zor anlaşılır olur.

Olay-tabanlı iş akışları süreç zaman içinde bir hikâye olduğunda parlıyor. Her adım yeni bir olaya (onaylandı, reddedildi, zamanlayıcı tetiklendi, ödeme başarısız) tepki verir ve sonraki adımı belirler. Bu, duraklama, devam etme, yeniden deneme ve neden yapıldığını izleme açısından daha kolaydır.

Gerçek ödünler şunlardır:

• Basitlik vs dayanıklılık: istek-yanıt başlamak için daha basit, olay-tabanlı ise uzun gecikmeler için daha güvenli.
• Hata ayıklama stili: istek-yanıt doğrusal bir yol izler, iş akışları adımlar arasında iz sürmeyi gerektirir.
• Araçlar ve alışkanlıklar: olaylar iyi logging, korelasyon ID'leri ve net durum modelleri ister.
• Değişim yönetimi: iş akışları evrilip dallanırken, iyi modellenmiş olay-tabanlı tasarımlar yeni yolları daha iyi tutar.

Pratik bir örnek: yönetici onayı, finans incelemesi, sonra ödeme gereken bir masraf. Ödeme başarısız olursa çift ödeme olmadan yeniden denemeler istersiniz—bu doğal olarak olay-tabanlıdır. Eğer sadece "masraf gönder" ve hızlı kontroller varsa istek-yanıt yeterli olabilir.

Adım adım: gecikmeleri atlatan uzun süreli bir süreç tasarlamak

Uzun süreli iş süreçleri sıkıcı nedenlerle başarısız olur: bir tarayıcı sekmesi kapanır, bir sunucu yeniden başlar, onay üç gün durur veya bir ödeme sağlayıcısı zaman aşımına uğrar. Hangi modeli tercih ederseniz edin, bu gecikmeler için baştan tasarlayın.

Küçük bir durum seti tanımlayarak başlayın ve kayıt edip devam edebileceğinizden emin olun. Veritabanınızda şu anki durumu işaretleyemiyorsanız, gerçekten devam ettirilebilir bir iş akışınız yok demektir.

Basit bir tasarım sırası

1. Sınırları belirleyin: başlangıç tetikleyicisi, bitiş koşulu ve birkaç ana durum (Beklemede, Onaylandı, Reddedildi, Süresi Doldu, Tamamlandı).
2. Olayları ve kararları adlandırın: zaman içinde neler olabileceğini yazın (Submitted, Approved, Rejected, TimerFired, RetryScheduled). Olay isimlerini geçmiş zamanda tutun.
3. Bekleme noktalarını seçin: sürecin insan, dış sistem veya son tarih için durduğu yerleri belirleyin.
4. Adım başına zamanlayıcı ve yeniden deneme kuralları ekleyin: zaman geçince veya bir çağrı başarısız olunca ne olacağına karar verin (backoff, maksimum deneme, tırmanma, vazgeçme).
5. Sürecin nasıl devam edeceğini tanımlayın: her olayda veya callback'te kaydedilmiş durumu yükleyin, geçerli olduğunu doğrulayın, sonra bir sonraki duruma geçin.

Yeniden başlatmalardan kurtulmak için devam etmek için gereken minimum veriyi kalıcı hale getirin. Yeniden çalıştırmak için tahmin yürütmeye gerek kalmayacak kadar saklayın:

• Süreç örneği kimliği ve mevcut durum
• Bir sonraki kim hareket edebilir (atanan/rol) ve verdikleri karar
• Son tarihler (due_at, remind_at) ve tırmanma seviyesi
• Yeniden deneme meta verileri (deneme sayısı, son hata, next_retry_at)
• Yan etkiler için idempotency anahtarı veya "zaten yapıldı" bayrakları (mesaj gönderme, kartı tahsil etme)

Eğer saklanan veriden "nerede olduğumuz" ve "sonraki neye izin verildiği" yeniden oluşturulabiliyorsa, gecikmeler korkutucu olmaktan çıkar.

Yaygın hatalar ve nasıl önlenirler

Uzun süreli süreçler genelde gerçek kullanıcılar geldikten sonra bozulur. Bir onay iki gün sürer, bir yeniden deneme yanlış zamanda tetiklenir ve sonuç çift ödeme veya eksik denetim izi olur.

Yaygın hatalar:

• İnsan onayı beklerken bir HTTP isteğini açık tutmak. Zaman aşımına uğrar, sunucu kaynaklarını bağlar ve kullanıcıya "bir şey oluyor" izlenimi verir.
• Idempotency olmadan çağrıları yeniden denemek. Ağ hatası çift faturalar, tekrar e-postalar veya tekrarlanan "Onaylandı" geçişlerine yol açar.
• Süreç durumunu saklamamak. Durum bellek içinde kalıyorsa restart bunu siler. Sadece log'larda tutuluyorsa güvenli şekilde devam edemezsiniz.
• Bulanık bir denetim izi oluşturmak. Olaylar farklı saat dilimleri ve formatlarda olursa, olay anında bir olay veya uyumsuzluk sırasında zaman çizelgesine güvenilemez.
• Asenkron ve eşzamanlıyı tek bir doğruluk kaynağı olmadan karıştırmak. Bir sistem "Ödendi" diyor, başka bir sistem "Beklemede" diyor ve kimse doğruyu bilmiyor.

Basit bir örnek: masraf sohbet üzerinden onaylandı, bir webhook geç geldi ve ödeme API'si yeniden denendi. Durum saklanmamış ve idempotency yoksa yeniden deneme ödemeyi iki kere gönderebilir ve kayıtlar nedenini net şekilde açıklayamaz.

Çoğu düzeltme açık olmaya dayanır:

• Durum geçişlerini (Requested, Approved, Rejected, Paid) veritabanında, kim/neyle değiştirdiğini kaydederek saklayın.
• Her dış yan etki için idempotency anahtarları kullanın ve o anahtarın sonucunu saklayın.
• "Talebi kabul et" ile "işi bitir" adımlarını ayırın: hızlıca cevap verin, sonra iş akışını arka planda tamamlayın.
• Zaman damgalarını standartlaştırın (UTC), korelasyon ID'leri ekleyin ve hem isteği hem çıktıyı kaydedin.

Oluşturmadan önce hızlı kontrol listesi

Uzun süreli işler tek bir mükemmel çağrıdan çok, gecikmeler, insanlar ve hatalar sonrası doğru kalmakla ilgilidir.

Süreç için "devam etmek güvenli" ne demek bunu yazın. Uygulama ortada bir yerde yeniden başlarsa son bilinen adımdan tahmin etmeden devam edebilmeli.

Pratik kontrol listesi:

• Bir çökme veya deploy sonrası sürecin nasıl devam edeceğini tanımlayın. Hangi durum kaydediliyor ve hangi işler sonraki olarak çalışıyor?
• Her örneğe benzersiz bir süreç anahtarı verin (örn. ExpenseRequest-10482) ve net bir durum modeli oluşturun (Submitted, Waiting for Manager, Approved, Paid, Failed).
• Onayları yalnızca sonuç değil bir kayıt olarak tutun: kim onayladı veya reddetti, ne zaman ve not/yorum ile birlikte.
• Bekleme kurallarını eşleyin: hatırlatmalar, son tarihler, tırmanmalar, süresi dolma. Her zamanlayıcı için bir sahip atayın (yönetici, finans, sistem).
• Hata yönetimini planlayın: yeniden denemeler sınırlı ve güvenli olmalı, ayrıca veri düzeltmesi veya yeniden onay için insan müdahalesine düşen bir "inceleme gerekir" durumu olmalı.

Bir akıl testi: ödeme sağlayıcısı zaman aşımına uğradı ama kart zaten tahsil edildi. Tasarımınız iki kez tahsil etmeyi önlemeli ve sürecin yine de tamamlanmasına izin vermeli.

Örnek: son tarih ve ödeme yeniden denemesi olan masraf onayı

Senaryo: bir çalışan $120 taksi makbuzu gönderir. 48 saat içinde yönetici onayı gerekir. Onaylanırsa sistem çalışana ödeme yapar. Ödeme başarısız olursa güvenli şekilde yeniden dener ve net bir kayıt bırakır.

İstek-yanıt yürütmesi

İstek-yanıt API'lerde uygulama genellikle sürekli kontrol etmek zorunda olan bir konuşma gibi davranır.

Çalışan Gönder'e dokunur. Sunucu "Beklemede" durumuyla bir geri ödeme kaydı oluşturur ve bir ID döner. Yöneticiye bildirim gider, ama çalışan uygulaması değişiklikleri görmek için genelde sorgulama yapmak zorundadır: "GET reimbursement status by ID" gibi.

48 saatlik son tarihi uygulamak için ya gecikmiş kayıtları tarayan periyodik bir iş çalıştırırsınız ya da deadline zaman damgası saklayıp sorgularda kontrol edersiniz. İş gecikirse kullanıcılar eski durumu görebilir.

Yönetici onayladığında sunucu durumu "Approved" yapar ve ödeme sağlayıcısını çağırır. Eğer Stripe geçici bir hata döndürürse sunucu şimdi mi tekrar deneyecek, sonra mı yoksa başarısız mı sayacak karar vermelidir. Dikkatli idempotency yoksa yeniden deneme çift ödemeye yol açabilir.

Olay-tabanlı yürütme

Olay-tabanlı modelde her değişiklik bir kayıt gibidir.

Çalışan gönderir ve bir "ExpenseSubmitted" olayı üretilir. Bir iş akışı başlar ve ya "ManagerApproved" olayını bekler ya da 48 saat sonra tetiklenecek "DeadlineReached" zamanlayıcı olayını. Zamanlayıcı önce tetiklenirse iş akışı "AutoRejected" sonucunu ve gerekçesini kaydeder.

Onay gelince iş akışı "PayoutRequested" kaydeder ve ödemeyi dener. Stripe zaman aşımı verirse "PayoutFailed" hata koduyla kaydedilir, 15 dakika sonra yeniden deneme planlanır ve sadece idempotency anahtarı kullanılarak gerçekten "PayoutSucceeded" olduğu kaydedilir.

Kullanıcının gördüğü özet basit kalır:

• Onay bekleniyor (48 saat kaldı)
• Onaylandı, ödeme yapılıyor
• Ödeme yeniden denemesi planlandı
• Ödendi

Denetim izi bir zaman çizelgesi gibi okunur: gönderildi, onaylandı, deadline kontrol edildi, ödeme denendi, başarısız oldu, yeniden denendi, ödendi.

Sonraki adımlar: modeli çalışan bir uygulamaya dönüştürmek

Bir gerçek süreci seçip uçtan uca bir kez inşa edin, sonra genelleştirin. Masraf onayı, işe alım ve iade işlemleri iyi başlangıçlardır çünkü insan adımları, beklemeler ve hata yolları içerir. Hedefi küçük tutun: bir ana yol (happy path) ve en yaygın iki istisna.

Süreci ekranlar değil durumlar ve olaylar olarak yazın. Örneğin: "Submitted" -> "ManagerApproved" -> "PaymentRequested" -> "Paid", dallanmalar "ApprovalRejected" veya "PaymentFailed" gibi olsun. Bekleme noktalarını ve yan etkileri net gördüğünüzde, olay-tabanlı iş akışları ile istek-yanıt API'leri arasındaki seçim pratik hale gelir.

Süreç durumunun nerede tutulacağına karar verin. Akış basitse bir veritabanı yeterli olabilir ve tek bir yerde güncellemeleri zorlayabilirsiniz. Zamanlayıcılar, yeniden denemeler ve dallanma gerekiyorsa bir iş akışı motoru hangi adımın sırada olduğunu takip ettiğinden yardımcı olur.

Başından itibaren denetim alanlarını ekleyin. Kim neyi yaptı, ne zaman oldu ve neden (yorum veya sebep kodu) saklayın. Birisi "Neden bu ödeme yeniden denendi?" diye sorduğunda log'larda kazmadan net cevap olmasını isteyeceksiniz.

Eğer bu tür bir iş akışını no-code bir platformda inşa ediyorsanız, AppMaster (appmaster.io) PostgreSQL'de veriyi modelleyip süreci görsel olarak oluşturmanıza izin veren bir seçenek olarak denemeye değerdir; bu, onaylar ve denetim izlerinin web ve mobil uygulamalarda tutarlı kalmasını kolaylaştırabilir.