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