Bir geliştiricinin uygulaması, Amazon SQS kuyruğundaki mesajları işlemek için bir AWS Lambda işlevi kullanıyor. Lambda işlevi bazen başarısız oluyor veya zaman aşımına uğruyor ve geliştiricinin işlenemeyen mesajları en az operasyonel yük ile yakalaması ve incelemesi gerekiyor. Bu gereksinimi hangi yaklaşım karşılar?

Doğru cevap, bir dead-letter queue (DLQ) oluşturmak ve başarısız mesajları bu DLQ'ya göndermesi için Lambda işlevini yapılandırmaktır. Bu yaklaşım, işlenemeyen mesajları otomatik olarak yakalar ve ayrı bir kuyrukta saklar, böylece geliştirici bunları daha sonra inceleyebilir ve yeniden işleyebilir. Bu, operasyonel yükü en aza indirir çünkü Lambda işlevinin kendisi mesajları manuel olarak işlemek zorunda kalmaz. Lambda işlevi zaman aşımını artırmak, sorunu çözmez; sadece işlevin daha uzun süre başarısız olmasına neden olabilir. AWS CloudTrail olay geçmişi, API çağrılarını kaydeder, ancak Lambda işlevinin içindeki hata ayrıntılarını sağlamaz. SQS kuyruğu görünürlük zaman aşımını artırmak, mesajların daha uzun süre görünmez kalmasına neden olabilir, ancak başarısız mesajları yakalamaz. Amazon CloudWatch Logs, hata ayrıntılarını içerebilir, ancak başarısız mesajları otomatik olarak bir yerde toplamaz. Amazon DynamoDB tablosuna başarısız mesajları yazmak, bir çözüm olsa da, DLQ'ya göre daha fazla geliştirme ve yönetim yükü getirir ve SQS'in yerleşik bir özelliği olan DLQ kadar entegre değildir.