Bir Web Uygulamasında Arka Plan İşleri: Kuyruklar, Zamanlayıcılar ve Cron

Bir web uygulamasında arka plan işlerini çalıştırmak için önce işi iki türe ayırın. Tetiklenen işler (hoş geldin e-postası göndermek, bir yüklemeyi işlemek) bir iş kuyruğuna, çoğu zaman veritabanınızdaki bir tabloya kaydedilebilir ve yeniden denemeleri olan bir işçi tarafından işlenebilir. Zamanlanmış işler (gecelik bir rapor, her 15 dakikada bir hatırlatma) bir zaman çizelgesinde tetiklenecek bir şey ister: barındırıcının cron özelliği ya da uygulamanızdaki korumalı bir uç noktayı çağıran harici bir zamanlayıcı. İşleri her zaman iki kez çalışsa bile güvenli yapın, hataları kaydedin ve uyuyabilen ya da yeniden başlayabilen bir sunucunun içindeki bir zamanlayıcıya asla güvenmeyin.

Bu rehber seçenekleri, her birinin ne zaman uygun olduğunu ve bunları bir yapay zeka uygulama oluşturucuyla, sıfıra ölçeklenen barındırıcılar dahil, nasıl kuracağınızı anlatır.

Arka plan işi neyi kapsar

Yavaş, güvenilmez ya da kullanıcının anlık yanıtı için gerekmeyen her şey:

E-posta, bildirim ve makbuz göndermek
Görselleri yeniden boyutlandırmak, video dönüştürmek, PDF üretmek
Yavaş üçüncü taraf API’lerini çağırmak; uzun görevler için yapay zeka modelleri dahil
Başka bir sistemden veri içe aktarmak ya da eşitlemek
Gecelik temizlik, raporlar ve hatırlatmalar

Bunu istek içinde yapmak sayfaları yavaş ve kırılgan yapar: e-posta sağlayıcısı çalışmıyorsa kullanıcının kaydı başarısız olur. Arka plana taşımak, kullanıcının anında yanıt almasını ve işin yeniden denenebilmesini sağlar.

Seçenekler

Seçenek	Nasıl çalışır	Artıları	Eksileri
Aynı süreçte ateşle-unut	Yanıt verin, işi sunucuda sürdürün	Kurulum yok	Sunucu durursa kaybolur; yeniden deneme yok
Süreç içi zamanlayıcı (`setInterval`, `setTimeout`)	Çalışan sunucudaki bir zamanlayıcı	Çok basit	Uykudayken çalışmaz; birkaç kopyada çoğalır
Veritabanı destekli kuyruk	İşler satır olarak kaydedilir; bir işçi bunları alıp çalıştırır	Zaten sahip olduğunuz veritabanını kullanır; kalıcıdır; incelemesi kolaydır	Yeniden denemeyi ve kilitlemeyi siz kurarsınız; işçiyi çalıştıracak bir şey gerekir
Ayrılmış kuyruk (Redis tabanlı ya da yönetilen)	Bir kuyruk servisi ve işçiler	Olgun yeniden deneme ve zamanlama özellikleri	Çalıştırılacak ve ödenecek başka bir servis
Barındırılan iş ya da iş akışı servisi	Üçüncü bir taraf, yeniden denemeler ve zamanlamalarla uç noktalarınızı çağırır	Zamanlama ve yeniden deneme sizin yerinize yapılır	Satıcıya bağımlılık; başka bir hesap ve anahtar
Uç noktayı çağıran harici zamanlayıcı	Başka bir yerdeki bir zamanlayıcı, zamanında bir HTTP isteği gönderir	Sıfıra ölçeklenen barındırıcılar dahil her yerde çalışır	Minimum aralıklar ve gecikmeler; uç noktayı korumak gerekir
Barındırıcının yerleşik cron’u	Platform bir komutu zamanlanmış olarak çalıştırır	Var olduğu yerde basittir	Her barındırıcı bunu sunmaz

Tek bir doğru cevap yoktur. Küçük bir uygulama çoğu zaman yalnızca bir veritabanı kuyruğuna ve harici bir zamanlayıcıya ihtiyaç duyar.

Sıfıra ölçeklenen barındırıcılar durumu neden değiştirir

Birçok modern barındırıcı, kimse kullanmadığında uygulamanızı uyutur ve bir sonraki istekte uyandırır. Bu para tasarrufu sağlar, ama uyuyan bir sunucu kod çalıştırmaz: zamanlayıcılar ateşlenmez, işçiler yoklama yapmaz. Bu barındırıcılarda zamanlanmış işin gelen bir istekle başlaması gerekir ve bu isteğin en kolay kaynağı harici bir zamanlayıcıdır. Her çağrı uygulamayı (ve çoğu zaman veritabanını) uyandırır, bu yüzden her dakika çağırmak her 15 dakikada bir çağırmaktan daha pahalıdır. İhtiyacı karşılayan en yavaş takvimi seçin.

1. örüntü: bir veritabanı iş kuyruğu

Tetiklenen işler için:

Bir jobs tablosu oluşturun: tür, yük (JSON), durum (pending, running, done, failed), deneme sayısı, run_after, last_error, zaman damgaları.
Bir şey olduğunda, bunu tetikleyen değişiklikle aynı işlemde bir iş satırı ekleyin; böylece ikisi birlikte başarılı ya da başarısız olur.
Bir işçi zamanı gelmiş işleri alır, running olarak işaretler, işi yapar ve done olarak işaretler.
Başarısızlıkta attempts değerini artırın, run_after değerini daha ileri bir zamana ayarlayın (örneğin 1, 5, sonra 30 dakika) ve hatayı kaydedin. Bir üst sınırdan sonra failed olarak işaretleyin ve birine haber verin.

Birden fazla işçi aynı anda çalışabilecekse, işler güvenli biçimde alınmalıdır. Postgres’te SELECT ... FOR UPDATE SKIP LOCKED her işçinin çakışmadan farklı satırları almasını sağlar.

İşçiyi ne çalıştırır? Her zaman açık bir sunucuda, ayrı bir süreçteki bir döngü. Sıfıra ölçeklenen bir barındırıcıda ise 2. örüntüdeki zamanlanmış uç nokta, her çağrıda zamanı gelmiş işlerden bir parti işleyebilir.

2. örüntü: uygulamanızı çağıran harici bir zamanlayıcı

Zamanlanmış işler için:

POST /api/cron/send-reminders gibi bir uç nokta ekleyin.
Koruyun: bir başlıkta gizli bir belirteç isteyin, bunu iki tarafta da gizli değer olarak saklayın ve başka her şeyi reddedin.
Idempotent yapın: aynı dakikada iki kez çalışması iki hatırlatma göndermemelidir. Neyin gönderildiğini kaydedin.
Her çağrıyı kısa tutun: bir parti işleyin (diyelim 100 öğe) ve kalanı bir sonraki çağrının almasına izin verin.
Bir zamanlayıcıyı buraya yönlendirin.

Zamanlayıcı seçenekleri:

GitHub Actions zamanlanmış iş akışları. GitHub’ın kullanım sınırları içinde ücretsiz. GitHub’ın belgelerine göre Eylül 2026 itibarıyla en kısa aralık 5 dakikada bir; meşgul saatlerde (özellikle her saatin başında) çalıştırmalar gecikebilir; zamanlamalar varsayılan olarak UTC kullanır; herkese açık bir depodaki zamanlanmış iş akışları, depoda 60 gün etkinlik olmazsa devre dışı bırakılır.
Barındırılan cron servisleri. Tek işi belirli zamanlarda bir URL’yi çağırmak olan birçok servis var. Birine bağlanmadan önce güvenilirliğini, minimum aralığını ve uyarı özelliklerini kontrol edin.
Bulut sağlayıcınızın zamanlayıcısı. Zaten büyük bir bulut sağlayıcısı kullanıyorsanız, bir HTTPS uç noktasını çağırabilen yönetilen bir zamanlayıcısı vardır.
Barındırılan bir iş ya da iş akışı servisi. Zamanlamayı, kuyrukları ve yeniden denemeleri birleştirir ve her adımda uç noktalarınızı çağırır. Fiyatlandırmayı ve sınırları her satıcının sitesinden karşılaştırın.

3. örüntü: işi sağlayıcıya bırakın

Bazen en iyi arka plan işi hiç olmayan iştir:

Ödemeler. Stripe başarısız abonelik ödemelerini yeniden dener ve webhook gönderir; siz yoklamak yerine tepki verirsiniz. Bkz. webhook nedir.
E-posta. Mesajı teslim ettiğinizde sağlayıcılar teslimatı kuyruğa alır ve yeniden dener.
Toplu yapay zeka işleri. OpenAI ve Anthropic, acil olmayan istekleri gönderip daha sonra toplamanızı sağlayan toplu API’ler sunar.

Yapay zeka oluşturucunuza verebileceğiniz komutlar

Bir kuyruk için:

Veritabanımızdaki bir jobs tablosunu kullanarak bir arka plan iş kuyruğu ekle (tür, JSON yük, durum, attempts, run_after, last_error). Bir kullanıcı kayıt olduğunda, e-postayı satır içinde göndermek yerine aynı işlemde bir send_welcome_email işi ekle. Zamanı gelmiş işleri SELECT ... FOR UPDATE SKIP LOCKED ile alıp çalıştıran, hataları 1, 5 ve 30 dakika sonra yeniden deneyen ve 4 denemeden sonra failed olarak işaretleyen bir processJobs(limit) fonksiyonu ekle.

Zamanlanmış bir tetikleyici için:

Gizli CRON_SECRET değerinden alınan bir bearer belirteciyle korunan POST /api/cron/tick ekle; belirteç olmadan gelen her isteği reddet. Her çağrı processJobs(100) çalıştırsın ve önümüzdeki 24 saat içinde gönderilmesi gereken, henüz gönderilmemiş rezervasyon hatırlatmalarını göndersin; gönderilen hatırlatmaları kaydet ki hiçbiri iki kez gönderilmesin. Çalışanların bir JSON özetini döndür. Ardından bu uç noktayı her 15 dakikada bir çağıran bir GitHub Actions iş akışı yaz; URL’yi ve belirteci depo gizli değerlerinden okusun.

Sık yapılan hatalar

setInterval’e güvenmek. Sunucu uyuduğunda ya da yeniden başladığında sessizce durur, iki kopya çalıştığında ise çiftlenir.
Korunmayan cron uç noktası. Onu bulan herkes işlerinizi, ya da e-posta faturanızı tetikleyebilir.
Idempotent olmayan işler. Yeniden denemeler ve yinelenen zamanlayıcı çağrıları olacaktır. Bunlara göre tasarlayın.
Hataların görünmemesi. Bir hafta boyunca sessizce başarısız olan bir iş, yüksek sesle başarısız olandan daha kötüdür. Hataları kaydedin ve tekrarlayan başarısızlıklarda uyarın.
Tek bir istekte uzun çalışmalar. İstekler zaman aşımına uğrar. Parti parti işleyin.
Çok sık zamanlama. Sıfıra ölçeklenen bir barındırıcıda her çağrı uygulamayı uyandırır ve faturalandırır. Aralığı gerçek ihtiyaca göre seçin.
Saat dilimleri. “Sabah 9” zamanlayıcınız (çoğu zaman UTC) ile kullanıcılarınız için farklı şeyler ifade eder. Zamanları UTC olarak saklayın ve kullanıcı başına dönüştürün.
İş akışı dosyasında gizli bilgiler. Belirteçleri zamanlayıcının gizli değer deposunda tutun. Bkz. API anahtarlarını güvende tutma.

Kontrol listesi

Yavaş işler kullanıcı isteklerinden çıkarıldı
İşler yalnızca bellekte değil, kalıcı olarak saklanıyor
Artan gecikmeli ve bir üst sınırlı yeniden denemeler var
Her iş iki kez çalışsa da güvenli
Zamanlanmış uç nokta gizli bir belirteçle korunuyor
Her çalışma sınırlı bir parti işliyor
Başarısız işler görünür ve uyarılar var
Zamanlama aralığı barındırma maliyeti düşünülerek seçildi
Zamanlar UTC olarak saklanıyor

Mythex’te arka plan işleri

Mythex’in belgeleri zamanlanmış ya da cron işlerini açıklamaz ve yayınlanmış uygulamalar ile veritabanları boşta kaldığında uyur, bir sonraki istekte uyanır (bkz. Barındırma limitleri). Bu yüzden uygulamanızın içindeki zamanlayıcılara güvenmeyin. İşe yarayan yaklaşım yukarıdakidir: ajandan bir jobs tablosu ve belirteçle korunan bir uç nokta isteyin, ardından harici bir zamanlayıcıyı yayınlanmış URL’nize yönlendirin. Belirteci proje gizli değeri olarak saklayın ve her uyanışın uygulama ve veritabanı uyanık kaldığı süre için kredi harcadığını unutmayın, bu yüzden makul bir aralık seçin. Uygulamanızın bunun için bir API arka ucuna ihtiyacı varsa, REST API arka ucu tarifi bir başlangıç noktasıdır; REST API nasıl oluşturulur rehberi uç noktaların tasarımını anlatır. Ürününüzün çekirdeği sürekli çalışan işçiler ya da botlarsa, kalıcı süreçler için tasarlanmış bir barındırıcı daha uygun olabilir.

Sorular

Arka plan işi nedir?

Arka plan işi, uygulamanızın bir kullanıcının beklediği istek dışında yaptığı iştir; örneğin e-posta göndermek, görselleri yeniden boyutlandırmak, rapor üretmek ya da veri eşitlemek. Kullanıcı hızlı bir yanıt alır, iş ayrı çalışır ve başarısız olursa yeniden denenebilir.

Barındırıcımda cron yoksa zamanlanmış bir görevi nasıl çalıştırırım?

İşi yapan korumalı bir uç nokta ekleyin, ardından harici bir zamanlayıcının bunu belirli saatlerde çağırmasını sağlayın. Seçenekler arasında zamanlanmış bir GitHub Actions iş akışı, barındırılan bir cron servisi ya da bulut sağlayıcınızın zamanlayıcısı var. Uç noktayı gizli bir belirteçle koruyun.

Zamanlanmış işler için setInterval ya da setTimeout kullanabilir miyim?

Yalnızca her zaman açık olan bir sunucuda küçük ve önemsiz görevler için. Sunucu yeniden başlarsa, sıfıra ölçeklenirse ya da birkaç kopya çalışıyorsa zamanlayıcılar kaybolur ya da birden fazla kez çalışır. Zamanlanmış işleri bir veritabanında tutun ya da bir zamanlayıcı kullanın.

Mythex cron işlerini destekliyor mu?

Mythex’in belgeleri zamanlanmış ya da cron işlerini açıklamaz ve yayınlanmış uygulamalar boşta kaldığında uyur. Güvenilir yaklaşım, uygulamanızdaki korumalı bir uç noktayı çağıran harici bir zamanlayıcıdır; bu uygulamayı uyandırır ve işi çalıştırır.