Logistics Flow neden BullMQ değil, RabbitMQ üzerinde çalışıyor

Netorigo altyapısı varsayılan olarak BullMQ kullanır: Redis zaten mevcut, geliştiriciler onu tanıyor ve çoğu iş için fazlasıyla yeterli. Yine de Logistics Flow (netorigo-app-logistics reposu) bu kalıbı bozdu ve RabbitMQ'yu seçti. Mesele “daha iyi teknoloji” değildi — üç somut nedene dayanıyordu.

1. neden: konu (topic) bazlı yönlendirme

Tek bir kargo olayı (ör. shipment.created.hu.budapest) yedi tüketiciye dağılır: gümrük, depo, filo, faturalama, müşteri bildirimi, analitik, denetim. Bir RabbitMQ topic exchange bunu tek bir yayınla halleder — BullMQ ile aynı akış 7 kuyruk ve 7 yazma anlamına gelirdi.

2. neden: birinci sınıf vatandaş olarak dead letter queue

• Lojistik olaylarının kabaca %1'i doğrulama hatasına takılır
• Bunlar gözden çıkarılabilir mesajlar değildir — her gönderi gerçek bir yüktür
• RabbitMQ'da DLQ yerleşiktir ve arayüzden yeniden oynatılabilir
• BullMQ'da yeniden deneme / başarısız durumunu ayırmak daha zordur
• Sorumlu bir kişi DLQ'yu her gün inceler

3. neden: kuyruk derinliği izleme

RabbitMQ yerel Prometheus metrikleri sunar: kuyruk derinliği, yayın hızı, tüketici sayısı, onay (ack) hızı. Grafana'da tek tıkla hangi tüketicinin yavaşladığı görülür. BullMQ ile aynısını elle geliştirmemiz gerekirdi ve depo ekibi 4 hafta sonra canlıya geçerdi.

Ders şu: kuyruğu teknik savunmaya göre seçmeyin. Bir mesaj kaybolduğunda kimin hesap vereceğine göre seçin. RabbitMQ bu sorumluluğu daha net hale getirir.

Geçişten sonra öğrendiklerimiz

• RabbitMQ bellek sınırını her zaman yapılandırın — aksi halde kontrolden çıkan tek bir tüketici broker'ı tıkar
• Publisher confirms varsayılan olarak kapalıdır; açın, aksi halde teslimat garanti edilmez
• Kuyruk tanımlarını arayüzden tıklayarak değil, kodda tutun — aksi halde felaket kurtarmada uygulanacak bir şey olmaz
• Grafana kontrol panelini yalnızca geliştiriciler değil, operasyon ekibi de kullanmalı — daha iyi SLA algısı
• Staging ve canlı ortam ayrı vhost'larda olmalı, asla aynısında değil

Bir şeyi daha söylemekte fayda var: BullMQ lojistik reposundan kaybolmadı. Kısa, hafif işler (e-posta gönderimi, cron tetikleyicileri, önbellek ısıtma) için BullMQ hâlâ çalışıyor. RabbitMQ yalnızca gerçek iş olaylarını taşıyor. İkisi arasındaki fark doğru kullanımdadır — hiçbiri diğerinden “daha iyi” değildir.