Gece yarısı saat 12:00’de cron job’unuz her gece olduğu gibi çalışmaya başlar. Ancak bu gece, 400 değil 40.000 aktif aboneniz var. Job, o gün süresi dolacak her aboneliği şarj etmeye başlar ve birkaç saniye içinde veritabanı bağlantılarınız tıkanır. Stripe 429 Too Many Requests hataları döndürmeye başlayabilir, ardından PHP zaman aşımına uğrar. Kimin şarj edildiğini, kimin edilmediğini bilemezsiniz. Bu, gece yarısı cron kabusudur. Abonelik faturalandırma sistemlerinde en yaygın ancak önlenebilir hatalardan biridir ve neredeyse her kendi backend’ini yazan ekip bir noktada bununla karşılaşır.
Basit yaklaşım ilk başta iyi görünür: Subscription::where('ends_at', '<=', now())->each(...). Ancak bu yöntem ölçeklendikçe dört büyük sorun ortaya çıkar: 1) Tüm yenilemeler aynı anda yapılır (darboğaz). 2) Senkron şarj, foreach içinde API çağrıları toplam süreyi saatlere çıkarır. 3) Stripe ve veritabanı hız sınırlaması uygular. 4) Idempotency yoksa, job çöktüğünde yeniden çalıştırmak çifte şarja yol açar. Bu sorunlar birkaç bin aboneden sonra kaçınılmazdır.
Profesyonel çözüm, üç şeyi yeniden düşünmeyi gerektirir: ne zaman, nasıl ve hangi kanıtla. İlk olarak, faturalandırma pencerelerini yayın: renewal_due_at ve ends_at ayrılsın. Yenileme denemesi, süre bitiminden bir iki gün önce yapılsın. İkinci olarak, asla zamanlayıcı içinde senkron şarj yapmayın. Zamanlayıcı sadece iş dağıtsın: chunkById ile 200’er gruplar halinde ProcessRenewal job’larını kuyruğa gönderin. Laravel 13’ün Queue::route() özelliği ile kuyruk bağlantısını merkezi olarak tanımlayın. Kuyruk işçileri doğal olarak eşzamanlılığı sınırlar, başarısız işleri yeniden dener ve tüm uygulamayı çökertmez.
Önemli Gelişmeler
Üçüncü adım, her yenileme denemesini idempotent hale getirmektir. Job’un handle metodunda, aboneliğin renewal_due_at’i ileri alınmışsa (başarılı) veya auto_renew kapatılmışsa (başarısız) işlemi atlayın. Bu sayede yeniden denemeler çifte şarja yol açmaz. Sonuç olarak, doğru tasarlanmış bir sistem: zamanlama yayarak, kuyruklama ile yükü dağıtarak ve idempotency ile güvenlik sağlayarak ölçeklenebilir ve güvenilir olur. Gece yarısı cron job’unuz artık bir kabus değil, sadece bir arka plan görevi haline gelir.
