В чём проблема такого решения (коммит после ответа внешнего REST-сервиса)?
Как вам кажется, это решение вообще нерабочее?
Можно ли освободить поток Kafka consumer, переложив сообщение в очередь в памяти и обрабатывая его в другом потоке?
Где появился outbox в вашей схеме — вы сначала писали в outbox из Kafka, а потом уже публиковали из outbox?
Почему именно Transactional Outbox — ведь можно было сделать иначе, например коммитить в Kafka только после успешной отправки?
За счёт чего вы сделали гарантированную доставку сообщений?
Какой из этих вариантов вам лично больше нравится?
Что вы имеете в виду под смешанным подходом?
Какой подход вам больше нравится: когда аналитик жёстко фиксирует решение или когда решение полностью на стороне разработчика?
А чем в таком случае руководствуются при выборе технического решения?
Изменение последовательного процесса на параллельный — где-то это фиксировалось?
Как правило, для таких изменений пишут sequence-диаграммы — это так фиксировалось у вас?
Как фиксируются системные требования — только в задачах, а аналитик их описывает?
Как раньше был описан этот сценарий/флоу аналитики, по результатам каких документов и артефактов?
Почему вы решили кэшировать клиента именно в Redis?
Задача была сформулирована как «уменьшить латенси», а решение для этого вы искали сами?
Задача пришла к вам в той формулировке, которую вы озвучили, или иначе? Как именно звучала исходная формулировка задачи?
На основании каких показателей вы решили, что задача стоит затраченных усилий?
Что было неудовлетворительным в исходной ситуации, из-за которой возникла задача?
Архитектура, которую вы меняли в ходе реализации задачи, была ли где-то прежде описана?