Konuyu Açan
#1
Bir sipariş oluşturulurken aynı transaction içinde e-posta veya faturalama işi kuyruğa atıldığında, worker işi veritabanı commit edilmeden alırsa kaydı bulamayabilir. Bu yüzden şu kullanım ilk bakışta iyi bir çözüm gibi duruyor:
Laravel’in kuyruk bağlantısındaki
Transaction commit edildikten sonra uygulama süreci çöker, ama kuyruk mesajı broker’a gönderilemezse veritabanında sipariş bulunur fakat ilgili iş hiç çalışmaz. Kritik akışlarda outbox yaklaşımı bu boşluğu kapatabiliyor: mesajı temsil eden kayıt aynı veritabanı transaction’ında yazılıyor, ayrı bir süreç de bunu kuyruğa aktarıyor. Tabii bu kez yinelenen teslimat ihtimaline karşı işleyicinin idempotent olması gerekiyor.
Kendi projelerinizde hangi eşiğe kadar
KOD
123456
DB::transaction(function () {
$order = Order::create([...]);
ProcessOrder::dispatch($order->id)->afterCommit();
});
Laravel’in kuyruk bağlantısındaki
after_commit ayarı da benzer bir davranış sağlayabiliyor. Benim merak ettiğim, bunun hangi noktaya kadar yeterli olduğu.Transaction commit edildikten sonra uygulama süreci çöker, ama kuyruk mesajı broker’a gönderilemezse veritabanında sipariş bulunur fakat ilgili iş hiç çalışmaz. Kritik akışlarda outbox yaklaşımı bu boşluğu kapatabiliyor: mesajı temsil eden kayıt aynı veritabanı transaction’ında yazılıyor, ayrı bir süreç de bunu kuyruğa aktarıyor. Tabii bu kez yinelenen teslimat ihtimaline karşı işleyicinin idempotent olması gerekiyor.
Kendi projelerinizde hangi eşiğe kadar
afterCommit kullanıyorsunuz? Outbox’a geçmenizi gerektiren somut ihtiyaç ne oldu; yoksa ek işletim karmaşıklığı çoğu uygulamada faydasından ağır mı geliyor?