Как правильно заметили, будет сложно, так как переключать мозги на

асинхронщину - очень сложно.
Вам действительно нужна асинхронная модель для взаимодействия?
Может, проще будет начать с синхронной модели через какой-нибудь service-mesh типа Istio?
А потом уже переходить на kafka?

P.S. по моему опыту:
1) Да, лучше не использовать спринговых обвязок вокруг кафки, чем ближе к низкому уровню, тем надежнее.
2) Заранее предусмотреть canary deploy (что на kafka не очень очевидно)
3) Заранее придумать, что будете делать, если в проде кто-нибудь кафку уронит (а так точно будет) и какие-то события, накопившиеся в буфере на producer никуда не дойдут.
4) Очень внимательно изучите все настройки consumer/producer/topic/broker и напишите подробный документ по их значениям для ваших конкретных целей (а то цели у всех разные и насторойки из коробки рассчитаны больше на пропускную способность, чем на гарантии).
А уж после этого что будет в топике и как его обрабатывать - будет понятно )

асинхронная модель - она сегодня везде, даже на rest сервисах. это скорее проблема не кафки, а reactive архитектур в целом. если есть опыт в reactive, то кафка но него ложится вполне ок.

IMO сравнивать kafka и istio (или linkerd etc) не совсем корректно. они скорее дополняют друг-друга чем конкурируют. kafka - это прежде всего data integration platform / write side. на istio можно вполне строить read side. весь value kafka (и kafka streams конкретно) - это data in motion. те когда одно же сообщение в топике это одновременно и запись в key-value store и нотификация другим сервисам - это круто и сразу решает целый ряд серьезных проблем. ничего похожего в istio et al нет и не будет, нужно пилить самому и это далеко не просто. в то же время на query side возможности каfka очень ограничены, и на istio можно вполне реализовать query side которая будет тащить данные из какой-нибудь read side database которая, в свою очередь, набивается из kafka