RabbitMQ, Kafka, Azure Service Bus gibi mesaj kuyrukları "en az bir kez teslim" (at-least-once) mantığıyla çalışır. Yani aynı mesaj ağ sorunu yüzünden iki kez gelebilir. "Mesaj bir kez gelir" varsayımıyla yazılmış kod, canlı ortamda çift sipariş, çift e-posta veya çift ödeme üretebilir.
Tekrarlanabilirlik anahtarı (idempotency key), mesajı işleyen tarafta rastgele üretilmemeli. Anahtar, mesajı gönderen tarafta ve iş kuralına bağlı olmalı — örneğin e-ticarette musteriId:siparisId:OdemeAl. Anahtarın yaşam süresi (TTL) de sipariş süresine uygun olmalı; sipariş yedi gün açık kalıyorsa anahtar da o kadar yaşamalı, varsayılan 24 saat yetmez.
Veritabanı kaydı ile olay yayınlama aynı işlemde (transaction) olmalı. Outbox deseni burada devreye girer: veritabanına "gönderilecek mesaj" yazılır, arka planda kuyruğa aktarılır. Yeniden denemede aynı olay kimliği (eventId) gitsin ki alıcı taraf tekrarı ayıklayabilsin (dedupe). "Önce kuyruğa gönder, sonra veritabanına yaz" sırası sessiz veri kaybına yol açabilir.
Yan etkiler — e-posta, ödeme, stok düşümü — tekrarlanabilirlik kontrolünden sonra gelmeli. Bozuk mesaj (poison message) sonsuz yeniden denemeye girmesin; birkaç denemeden sonra ölü mektup kuyruğuna (DLQ) ve uyarıya gitsin. Yayınlamadan önce tek soru yeter: "Aynı mesaj iki kez gelirse ne olur?" Cevabın kodda ve testte görünür olmalı.
Özet: Mesaj kuyrukları çift teslimat yapabilir. Anahtar iş kuralına bağlı olmalı; ödeme ve stok gibi yan etkiler kontrol sonrası çalışmalı.