Это дополнительные 4 топика от спринга для ретрая -retry-0, -retry-1, -retry-2, -dlx , последний это топик неудачных сообщений. И оригинальный топик еще.
С точки зрения формулировки, да, правильнее говорить в таком случае именно 3 ретрая, если первую попытку не считать. Но в целом N топиков дополнительно создается для обеспечения N попыток отправки всего.
А С4 тоже as code? Или надо рисовать руками. Может будет интеграция со structurizr?) Можно тоже отдаю ему на сторону рендеринг, он умеет запускаться self-hosted
Очень интересная статья, с точки зрения исследования, экспериментов и набивания шишек. Но сложновато и правда. Если это сугубо инструмент теханализа, он вообще может решить целевую задачу?
Пример: допустим нужно 4 попытки отправки.
Это дополнительные 4 топика от спринга для ретрая
-retry-0,-retry-1,-retry-2,-dlx, последний это топик неудачных сообщений. И оригинальный топик еще.Получается 4 попытки (оригинал -> 0, 0 -> 1, 1 -> 2, 2 -> dlx).
С точки зрения формулировки, да, правильнее говорить в таком случае именно 3 ретрая, если первую попытку не считать. Но в целом N топиков дополнительно создается для обеспечения N попыток отправки всего.
Да, согласен что это странно, хотя бы доступное количество ядер бы взяли
да, это под капотом делает spring-kafka в ListenerContainerPauseService
А С4 тоже as code? Или надо рисовать руками. Может будет интеграция со structurizr?) Можно тоже отдаю ему на сторону рендеринг, он умеет запускаться self-hosted
Очень интересная статья, с точки зрения исследования, экспериментов и набивания шишек. Но сложновато и правда. Если это сугубо инструмент теханализа, он вообще может решить целевую задачу?