Kuyruk Sistemleri ve Background Job İşleme Rehberi [2026]

Asenkron Isleme Neden Gerekli?

Modern web uygulamalarinda her islemin kullanici istegi sirasinda senkron olarak tamamlanmasi ne mumkundur ne de gereklidir. E-posta gonderimi, rapor olusturma, gorsel isleme, veri aktarimi ve ucuncu parti API cagirilari gibi islemler zaman alici olabilir. Bu islemleri kullanicinin HTTP yanit suresi icinde tamamlamaya calismak, hem kullanici deneyimini olumsuz etkiler hem de sistem kaynaklarini verimsiz kullanir.

Kuyruk sistemleri ve background job isleme, bu sorunu cozen temel mimari yapilardir. Zaman alici islemler bir kuyruga eklenir ve arka planda calisan worker'lar tarafindan islenir. Boylece kullanici aninda yanit alirken, agir islemler sistemin kapasitesine gore asenkron olarak tamamlanir.

Bu yaklasim ayni zamanda sistemin dayanikliligini da arttirir. Senkron islemede bir hata tum istegi basarisiz kilarken, kuyruk tabanli islemede basarisiz gorevler tekrar denebilir. Trafik ani artislarinda kuyruk tampon gorevi gorerek, backend servislerinin asiri yuk altinda kalmasini engeller.

Mesaj Kuyrugu Desenleri

Kuyruk sistemleri farkli iletisim desenlerini destekler. Dogru deseni secmek, sistemin gereksinimlerine uygun mimariyi kurmak icin kritik onem tasir.

Work Queue (Gorev Kuyrugu)

En temel desen olan work queue'da, ureticiler (producers) gorevleri kuyruga ekler ve tuketiciler (consumers/workers) bu gorevleri sirayla isler. Her gorev yalnizca bir worker tarafindan islenir. E-posta gonderimi, gorsel boyutlandirma ve rapor olusturma gibi senaryolar bu desene uygundur.

Work queue deseninde birden fazla worker calistirarak paralel isleme kapasitesi arttirilabilir. Gorevler worker'lar arasinda round-robin veya kapasite bazli dagitilir ve her gorev yalnizca bir kez islenir. Bu yapi, is yukunu yatay olarak olceklendirmeyi kolaylastirir. Worker'larin gorev islemesini onaylamasi (acknowledgement) icin acik onay mekanizmasi kullanilir; boylece bir worker cokerse, islenmeyen gorev otomatik olarak baska bir worker'a yonlendirilir.

Publish/Subscribe (Yayinla/Abone Ol)

Pub/sub deseninde, bir mesaj birden fazla abone tarafindan alinabilir. Ureticiler mesajlari bir topic veya exchange'e gonderir, ilgili tum aboneler bu mesajlari alir. Olay tabanli mimarilerde, bir islemin birden fazla sistemi tetiklemesi gerektigi durumlarda bu desen idealdir.

Ornegin bir siparis olusturuldugunda, stok guncelleme servisi, bildirim servisi ve analitik servisi ayni olayi dinleyerek kendi islemlerini bagimsiz olarak gerceklestirebilir. Servisler arasindaki bagimliligi azaltan bu yaklasim, sistemin genisletilebilirligini onemli olcude arttirir. Yeni bir servis eklemek icin mevcut servislerde degisiklik yapmaya gerek kalmaz.

Request/Reply (Istek/Yanit)

Bazen asenkron islemlerin sonucunu beklemek gerekebilir. Request/reply deseninde, istek kuyruga gonderilir ve yanit ayri bir kuyruk uzerinden geri alinir. Correlation ID mekanizmasi ile istekler ve yanitlar eslestirilir. Uzun suren hesaplamalar veya harici servis cagrilari icin bu desen kullanislidir. Ancak bu desen, asenkron islemin avantajlarini kismi olarak kaybettirir; bu nedenle gercekten gerekli oldugunda kullanilmalidir.

Teknoloji Karsilastirmasi

Kuyruk sistemi secimi, kullanim senaryosuna, olcek gereksinimlerine ve ekibin deneyimine gore sekillenmelidir.

Redis + BullMQ

Redis uzerine kurulu BullMQ, Node.js ekosisteminde en yaygin kullanilan kuyruk kutuphanesidir. Redis'in hiz ve basitligini, BullMQ'nun zengin ozellik setiyle birlestirerek guclu bir cozum sunar.

BullMQ'nun temel avantajlari arasinda oncelikli kuyruklar, tekrarlanabilir gorevler (cron-like scheduling), geciktirmeli gorevler, rate limiting, sandboxed worker'lar ve kapsamli olay sistemi yer alir. Redis zaten cogu projede onbellek icin kullanildigindan, ek altyapi gereksinimi minimumda kalir. TypeScript destegi ve modern API tasarimi, gelistirici deneyimini olumlu yonde etkiler.

Ancak Redis'in bellege dayali dogasi, buyuk mesaj hacimlerinde ve dayaniklilik gereksinimlerinde sinirliliklara yol acabilir. Redis'in calismadigi durumlarda mesaj kaybi riski vardir. Redis Sentinel veya Redis Cluster ile yuksek erisilebilirlik saglanabilir, ancak kritik is surecleri icin ek dayaniklilik onlemleri degerlendirilmelidir.

RabbitMQ

RabbitMQ, AMQP protokolunu uygulayan olgun ve guvenilir bir mesaj brokeridir. Karmasik yonlendirme senaryolari, exchange turleri (direct, topic, fanout, headers) ve mesaj onay mekanizmalari ile esnek bir mimari sunar.

RabbitMQ'nun guclu yanlari arasinda mesaj dayanikliligi (disk persistance), esnek yonlendirme, coklu protokol destegi (AMQP, MQTT, STOMP) ve yonetim arayuzu bulunur. Birden fazla programlama dilinin kullanildigi heterojen ortamlarda, dil bagimsiz mesajlasma altyapisi olarak idealdir. Prefetch count ayari ile worker'larin kapasitelerini asmasini onleyerek, kaynakların verimli kullanilmasini saglar.

Operasyonel karmasiklik ve kumeleme (clustering) yapilandirmasi, RabbitMQ'nun dikkat gerektiren yonleridir. Quorum queue'lar, klasik queue'lara kiyasla daha iyi veri guvenligi ve otomatik leader secimi saglar. Network partitioning senaryolari icin dogru strateji secimi (pause-minority, autoheal) onemlidir.

Apache Kafka

Kafka, yuksek hacimli veri akislari icin tasarlanmis dagitik bir akis platformudur. Log tabanli mimarisi, mesajlarin siralanmis ve dayanikli sekilde saklanmasini saglar. Geleneksel kuyruk sistemlerinden farkli olarak, Kafka mesajlari tuketildikten sonra silmez; belirli bir sure boyunca (veya sinirsize kadar) saklar.

Bu ozellik, mesajlarin tekrar islenebilmesini, farkli consumer gruplarin ayni verileri bagimsiz olarak tuketebilmesini ve olay kayitlarinin (event sourcing) olusturulabilmesini mumkun kilar. Kafka, saniyede milyonlarca mesaj isleyebilen kapasitesiyle buyuk olcekli veri pipeline'lari, log agregasyonu ve gercek zamanli analitik icin tercih edilir. Partition mekanizmasi ile paralel isleme ve siralama garantisi saglanir.

Ancak Kafka'nin operasyonel karmasikligi, ZooKeeper veya KRaft (Kafka Raft) bagimliligi ve kaynak gereksinimleri, kucuk ve orta olcekli projeler icin asiri olabilir. Basit gorev kuyrugu ihtiyaclari icin BullMQ veya RabbitMQ genellikle daha uygun secimlerdir.

Teknoloji Secim Rehberi

Node.js agirlikli projeler ve orta olcekli is yukleri icin Redis + BullMQ pragmatik bir baslangic noktasidir. Karmasik yonlendirme gereksinimleri ve coklu dil destegi gerektiren ortamlar icin RabbitMQ onerilir. Yuksek hacimli veri akislari, olay kaydi ve gercek zamanli islem gereksinimleri icin Kafka dogru secim olacaktir. Python ekosistemine odakli projelerde Celery, Ruby ekosisteminde ise Sidekiq olgun ve yaygin tercihler arasindadir.

Job Zamanlama ve Geciktirilmis Islemler

Background job'lar yalnizca anlik gorevler icin degil, zamanlanmis ve geciktirilmis islemler icin de kullanilir.

Cron Benzeri Zamanlama

Duzenli araliklarla calistirilmasi gereken gorevler (gunluk rapor olusturma, haftalik veri temizligi, saatlik metrik toplama, aylik fatura olusturma) cron benzeri zamanlama ile yonetilir. BullMQ'nun repeatable jobs ozelligi, cron ifadelerini destekleyerek bu ihtiyaci karsilar. Celery Beat ve Sidekiq-Cron da benzer islevsellik sunar.

Zamanlanmis gorevlerde dikkat edilmesi gereken en onemli nokta, birden fazla worker instance'inin ayni zamanlanan gorevi es zamanli olarak calistirmasinin onlenmesidir. Distributed lock mekanizmalari (Redis tabanli Redlock, veritabani tabanli advisory lock) veya leader election yaklasimlari bu sorunu cozer. Ayrica zamanlanmis gorevlerin calisma suresi, bir sonraki zamanlanmis calisma anini asmamalidir; aksi halde gorev birikmesi yasanabilir.

Geciktirilmis Gorevler

Belirli bir sure sonra calistirilmasi gereken gorevler (siparis sonrasi 24 saat icinde degerlendirme istegi, deneme suresi bitis hatirlatmasi, odeme vade tarihinde bildirim) geciktirilmis gorevler olarak kuyruga eklenir. BullMQ'da delay parametresi, RabbitMQ'da TTL ve dead letter exchange, Celery'de eta parametresi bu islevi saglar.

Retry Stratejileri ve Dead Letter Queue

Dagitik sistemlerde hatalar kacinilamzdir. Gecici ag sorunlari, servis kesintileri veya kaynak yetersizlikleri nedeniyle gorevler basarisiz olabilir. Dogru retry stratejisi, gecici hatalarin otomatik olarak cozulmesini saglarken, kalici hatalarin gereksiz yere tekrarlanmasini onler.

Exponential Backoff

Her basarisiz denemeden sonra bekleme suresini katlanarak artirmak (ornegin 1s, 2s, 4s, 8s, 16s) en yaygin retry stratejisidir. Bu yaklasim, gecici sorunlarin cozulmesi icin zaman tanirken, sistemin asiri yuk altinda kalmasini onler. Jitter (rastgele gecikme) eklemek, birden fazla basarisiz goreverin ayni anda tekrar denemesini (thundering herd) onler. Maksimum bekleme suresi (cap) belirlemek, gecikmenin kontrolsuz artmasini engeller.

Dead Letter Queue (DLQ)

Maksimum deneme sayisina ulasilmis ve hala basarisiz olan gorevler, dead letter queue'ya tasinir. DLQ, basarisiz gorevlerin kaybolmasini onler ve sonradan inceleme, duzeltme ve tekrar isleme imkani saglar. DLQ izleme, alarm mekanizmalariyla entegre edilerek operasyonel gorunurluk saglanmalidir. DLQ'daki gorevlerin kok neden analizi yapildiktan sonra toplu olarak tekrar isleme alinabilmesi icin araclar hazirlanmalidir.

Hata Kategorilendirme

Tum hatalara ayni retry stratejisini uygulamak verimsizdir. Gecici hatalar (ag zaman asimi, HTTP 503, servis gecici olarak kullanilamiyor) retry ile cozulebilirken, kalici hatalar (HTTP 400, gecersiz veri, yetkisiz erisim) tekrar denemeden dogrudan DLQ'ya yonlendirilmelidir. Hatalarin dogru kategorilendirmesi, gereksiz retry islemlerini onleyerek sistem kaynaklarini verimli kullanir ve gereksiz uyari gurultusunu azaltir.

Idempotency: Tekrarlanan Islemlerde Tutarlilik

Kuyruk sistemlerinde "en az bir kez teslim" (at-least-once delivery) garantisi, bir mesajin birden fazla kez islenmesine yol acabilir. Worker bir gorevi isleyip onay gondermeden once cokerse, kuyruk sistemi ayni gorevi baska bir worker'a iletir. Bu durumda gorev iki kez islenmis olabilir.

Idempotent islemler, ayni girdilerle birden fazla kez calistirildiginda ayni sonucu ureten islemlerdir. Bir e-postanin iki kez gonderilmesini veya bir odemenin iki kez islem gormesini onlemek icin idempotency kritik onem tasir.

Idempotency saglamanin yaygin yontemleri arasinda benzersiz islem kimligi (idempotency key) ile her goreve tekil bir anahtar atamak, islem oncesi veritabaninda durumu kontrol ederek daha once basarili sekilde islenip islenmedigini dogrulamak ve veritabani kisitlamalari (unique constraints) ile tekrarlanan kayitlari engellemek yer alir. Redis SET NX komutu ile dagitik ortamda idempotency kilidi uygulanabilir.

Oncelikli Kuyruklar ve Rate Limiting

Oncelik Yonetimi

Tum gorevlerin esit oncelikli olmadigi durumlarda, oncelikli kuyruklar kullanilir. Odeme islemleri rapor olusturmadan, acil bildirimler pazarlama e-postalarindan daha yuksek oncelikli olabilir. BullMQ'da priority parametresi (dusuk deger = yuksek oncelik), RabbitMQ'da priority queue ozelligi bu ihtiyaci karsilar.

Oncelik sistemi tasarlarken, dusuk oncelikli gorevlerin surekli ertelenmesi (starvation) sorununa dikkat edilmelidir. Adil zamanlama mekanizmalari, oncelik seviyeleri arasi oran belirleme veya dusuk oncelikli gorevler icin maksimum bekleme suresi tanimlama ile bu sorun yonetilebilir.

Rate Limiting

Harici API cagirilari veya kaynak yogun islemler icin rate limiting, sistemin asiri yuk altinda kalmasini ve harici servislerin limitlerine takilmasini onler. BullMQ'nun yerlesik rate limiter ozelligi, belirli zaman araliginda islenecek maksimum gorev sayisini sinirlar. Group bazli rate limiting ile farkli musteriler veya is turleri icin ayri limitler tanimlanabilir.

Rate limiting, ozellikle ucuncu parti API entegrasyonlarinda kritiktir. API saglayicisinin hiz limitlerini asmak, hesap askiya alinmasina veya gecici erisim engellerine yol acabilir. Token bucket veya sliding window algoritmalari ile hassas hiz kontrolu saglanabilir.

Izleme ve Gozlemlenebilirlik

Kuyruk sistemlerinin saglikli calistigini dogrulamak ve sorunlari erken tespit etmek icin kapsamli izleme gerekir.

Temel Metrikler

Kuyruk derinligi (bekleyen gorev sayisi), ortalama ve yuzdelik isleme suresi (p50, p95, p99), basari/basarisizlik orani, worker kullanim orani ve DLQ boyutu temel izleme metrikleridir. Kuyruk derinliginin surekli artmasi, isleme kapasitesinin yetersiz olduguna isaret eder. DLQ boyutunun artmasi ise sistematik bir hata oldugunu gosterir. Gorev bekleme suresi (kuyrukta gecen zaman) de SLA uyumu acisindan izlenmelidir.

Dashboard ve Alarmlar

BullMQ icin Bull Board veya Arena, Celery icin Flower, Sidekiq icin web arayuzu gibi araclar gorev durumlarini gorsellestirir. Bu araclarin yani sira, Prometheus ve Grafana gibi izleme platformlariyla entegrasyon, kapsamli metrik toplama ve alarm mekanizmalarini mumkun kilar.

Kuyruk derinligi esik degerleri, DLQ artis orani, worker saglik kontrolleri ve gorev isleme suresi anomalileri icin alarmlar tanimlanarak, sorunlar proaktif olarak tespit edilmelidir. Distributed tracing entegrasyonu ile gorevlerin uretimden islemeye kadar tum yasam dongusunun izlenebilmesi, sorun giderme surecini hizlandirir.

Worker Olceklendirme

Is yukune gore worker sayisini ayarlamak, hem maliyet etkinligi hem de performans icin onemlidir.

Yatay Olceklendirme

Worker'lar bagimsiz process'ler olarak calistigi icin yatay olceklendirme dogaldir. Kubernetes ortaminda HPA (Horizontal Pod Autoscaler), kuyruk derinligi veya isleme gecikmesi gibi metriklere gore worker pod sayisini otomatik olarak ayarlayabilir. KEDA (Kubernetes Event Driven Autoscaling) ise kuyruk spesifik metriklere dayali daha granular olceklendirme saglar; ornegin belirli bir kuyrukta 100'den fazla gorev biriktiginde yeni worker baslatilabilir.

Kaynak Yonetimi

CPU yogun gorevler (gorsel isleme, veri donusumu, PDF olusturma) ve I/O yogun gorevler (API cagirilari, veritabani islemleri, dosya yukleme) farkli kaynak profilleri gerektirir. Worker'lari gorev turune gore ayirmak ve kaynak limitlerini buna gore yapilandirmak, sistem kaynaklarinin verimli kullanilmasini saglar. Concurrency ayari ile her worker'in ayni anda kac gorev islediginin kontrolu, kaynak tasmasini onler.

Yaygin Kullanim Senaryolari

E-posta ve Bildirim Gonderimi

Toplu e-posta gonderimi, push bildirimleri ve SMS gonderimi en yaygin kuyruk kullanim senaryolaridir. Rate limiting ile saglayici limitlerini asma riski onlenir, retry mekanizmasi ile gecici hatalar yonetilir ve oncelik sistemi ile acil bildirimler one alinir. Template rendering isleminin worker tarafinda yapilmasi, ana uygulama sunucusunun yukunu azaltir.

Rapor Olusturma

Buyuk veri setleri uzerinde rapor olusturma islemleri dakikalar surebildiginden, bu islemler kuyruk uzerinden asenkron olarak islenir. Kullaniciya raporun hazirlaniyor oldugu bildirilir ve tamamlandiginda e-posta veya uygulama ici bildirim gonderilir. Buyuk raporlar icin chunked isleme yaklasimiyla veri parcalara bolunur ve sonuclar birlestirilerek nihai rapor olusturulur.

Veri Pipeline Isleme

ETL surecleri, veri donusumleri ve toplu veri aktarimlari kuyruk sistemleri uzerinden yonetilir. Gorevler arasindaki bagimliliklar, is akisi (workflow) yonetim katmanlari ile koordine edilir. BullMQ'nun Flow ozelligi, parent-child gorev iliskileri tanimlayarak karmasik pipeline'larin yonetilmesini saglar.

Webhook Teslimi

Harici sistemlere webhook gondermek, retry ve idempotency gereksinimlerinin en belirgin oldugu senaryolardan biridir. Smart Maple olarak gerceklestirdigimiz entegrasyon odakli projelerde, webhook teslim mekanizmalarinin guvenilir sekilde calismasi, is ortaklariyla saglıkli veri akisinin temelidir. Webhook teslim durumunun izlenmesi, basarisiz teslimlerin dashboard uzerinden goruntulenmesi ve manuel tekrar deneme imkani sunulmasi operasyonel acisindan onemlidir.

Sonuc

Kuyruk sistemleri ve background job isleme, modern yazilim mimarisinin vazgecilmez bilesenleridir. Dogru teknoloji secimi, saglam retry stratejileri, idempotency garantileri ve kapsamli izleme mekanizmalari ile guvenilir bir asenkron isleme altyapisi kurulabilir.

Basit ihtiyaclar icin Redis + BullMQ ile baslamak, sistem gereksinimleri buyudukce RabbitMQ veya Kafka'ya gecis yapmak pragmatik bir stratejidir. Hangi teknoloji secilirse secilsin, idempotency, hata yonetimi ve gozlemlenebilirlik prensiplerinin basindan itibaren uygulanmasi, uzun vadede saglikli bir sistem isletiminin temelini olusturur.