Dead Letter Queue в Kafka на практике

[arwyl]

правильно ли я понимаю, что если после отправки автокоммита произойдет лаг сети или просто рестарт сервиса, то сообщение ни до внешнего апи, ни до dlq не дойдет?

[Capta1n_Redbeard]

На случай лага сети есть те же ретраи в том числе и при отправке в Кафку, если же сам под должен будет перезапуститься, то отработает gracefull shutdown, который не даст сообщениям потеряться и завершит таски, которые уже в рантайме (либо отправиться в DLQ, либо во внешний API)

p.s. gracfull shutdown на ответственности разработчика

[arwyl]

я имею ввиду самый крайний случай, когда, например, время лага в сети будет больше времени, отведённого на gracefully shutdown

[Capta1n_Redbeard]

Тогда да, потеряем, но на то она и Кафка — сообщения можно перечитать, но это уже другая история

[arwyl]

спасибо! Это и предполагал, но подумал, что мало ли там какой-то персистенс лёгкий был еще

[reb00ter]

А не рассматривали outbox-паттерн для решения этой задачи? Кажется он решит проблему без dlq, с сохранением всей необходимой истории и ретраями произвольное количество раз.

При этом не будет риска потери данных при отказе ноды, и проблем с graceful shutdown особо не будет

[Capta1n_Redbeard]

Внешний апи может не иметь дедупликации на своей стороне, чтобы в случае сбоя мы просто как в outbox заново ему зарядили бы сообщения, которые из-за сбоя не пометили как прочитанные.

Я думаю, тут есть ещё точно достаточное кол-во вариантов, как реализовать. Просто решил осветить свой.