Fault Tolerance ve Resiliency İçin Dead-Letter Queue Örüntüsü

Giriş

Bir mesaj bir kaç defa denendikten sonra (Retry Örüntüsü) halen işlenemiyorsa muhtemelen insan müdahalesi gerekir. Dead Letter Channel aynı zamanda Dead Letter Queue olarak ta bilinir. Şeklen şöyle

Açıklaması şöyle

1. Under normal circumstances, the application processes each event in the source topic and publishes the result to the target topic
2. Events that cannot be processed, for example, those that don’t have the expected format or are missing required attributes, are routed to the error topic
3. Events for which dependent data is not available are routed to a retry topic where a retry instance of your application periodically attempts to process the events

Eğer birbirine bağımlı mesajlar varsa bunların da sırayı muhafaza etmek için aynı kuyruğa gönderilmesine dikkat etmek gerekir

Dead-Letter Kelime Anlamı Nedir?

Açıklaması şöyle.

What Is a Dead Letter Queue?
In English vocabulary, dead letter mail is undeliverable mail that cannot be delivered to the addressee. A dead-letter queue (DLQ), sometimes known as an undelivered-message queue, is a holding queue for messages that cannot be delivered to their destinations due to something.

According to Wikipedia — In message queueing the dead letter queue is a service implementation to store messages that meet one or more of the following failure criteria:

- Message that is sent to a queue that does not exist
- Queue length limit exceeded
- Message length limit exceeded
- Message is rejected by another queue exchange
- Message reaches a threshold read counter number because it is not consumed. Sometimes this is called a “back out queue”

İnsan Müdahalesi İçin Bazı Örnekler

Örnek

Bir örnek şöyle

A message arriving in the error queue can trigger an alert and the support team can decide what to do. And this is important: You don't need to automate all edge cases in your business process. What's the point in spending a sprint to automate this case, if it only happens once every two years? The costs will definitely outweigh the benefits. Instead, we can define a manual business process for handling these edge cases.

In our example, if Bob from IT sees a message in the error queue, he can inspect it and see that it failed with a CannotShipOrderException. In this case, he can notify the Shipping department and they can use another shipment provider. But all of this happens outside of the system, so the system is less complex and easier to build.

Örnek

Hatalı alan için bir örnek şöyle

However, if the error is not ever possible to solve via a retry process (such as a never ever unhandled case, maybe a corrupt field value, e.g.), you should create an “error topic” which is called a “dead-letter queue”.