Да, понятный паттерн.
Не понятный, например - это с одним инстансом кафки и одним инстансом zk организовывать локальный (в пределах l1/l2-связности) event-streaming.

А почему один брокер? Если бы там была СУБД - все равно поставил бы standby, если простой актуален. А если нет - то и пофиг )

С кафкой (и другими очередями) другая беда: при отказе брокера, а за ним продьюсера - теряются сообщения. Редкий кейс, но неприятный...

(есть варианты обхода, но не очень удобные...)

Отвечу "потому что так было можно сделать".
Прямо по тексту " Сейчас я вижу, что часто kafka используется как решение без понимания того, какие проблемы оно может принести в проект. "

Отказ какой имеется в виду? Сервер умер или просто брокер упал?

Так такие проблемы будут у любого брокера. В доке по Кафке хотя бы написано, что так делать можно только в тестовом окружении.

Брокер умер или сеть к брокеру умерла. Главное - что сообщения в буфере на продьюсере копиться начали.

А, я понял. Но это действительно крайне редкий случай.

Ну, для платежей приходится рассматривать.

У кафки есть кучка проблем:
1) дорогое создание топиков (т.е. не по создаешь на каждый платеж, например)
2) нет (насколько я помню) синхронного suspend send (для простой асинхронности на корутинах)
3) достаточно сложно делать свои политики управления распределением партиций (если нужна канарейка или dog-food)
4) Kafka connect нормальный только для Oracle+GoldenGate, для постгре пока сырой.
Все решается, но не всегда просто.
Но в остальных очередях - проблем еще больше.
Хотя Pulsar интересен, но пока еще не достаточно зрелый.

Для забора из БД для кафки есть https://debezium.io/

Еще вспомнил, чем мне кафка мешает. Максимальный размер сообщения. Можно и здесь сильно прогореть, если гонять по именно данные.

https://www.slideshare.net/merlimat/high-performance-messaging-with-apache-pulsar вот, нашел.

Ну, там размер настолько большой, что беда только если файлы гонять. Но если десятимегабайтные сообщения отправлять, то все  очереди будут ругаться.

Вот он и сырой пока )

rmq не будет. Ему не понравится с точки зрения перфоманса, но он съест. А кафка просто передать нельзя.

Ну, там на уровне топика можно подкрутить. Только не факт, что rmq съест, а не упадет, там по разному бывает...

Я видел систему, в которой средний размер сообщения 8кб. Для хранения документов была выбрана mongodb, в которой максимальный размер документа - 16Мб. Казалось, бы запас прочности - три порядка. Но нашлись документы размерами в 300Мб...