Чтобы независимые получатели Kafka читали одни и те же сообщения, каждому логическому подписчику назначают отдельную consumer group. Внутри одной обычной группы partition распределяются между участниками.
Consumer масштабируют по lag и пропускной способности обработки с учётом числа partition. В обычной группе лишние consumer сверх доступных partition не увеличивают параллелизм.
Ограничьте число попыток и общий retry-budget, используйте backoff с jitter, различайте временные и постоянные ошибки и снижайте нагрузку на недоступную зависимость.
Kafka доставляет и хранит поток событий, а Postgres может быть источником текущего состояния, транзакций и запросов клиента. Эти роли не взаимоисключающие.
At-least-once допускает повтор обработки при сбое. Kafka exactly-once для потоковой обработки связывает запись результата и offsets транзакцией, но не охватывает автоматически внешнюю БД или HTTP.
Разделите оптимизацию consumer-потока и RPC: где терялось время, какие гарантии сохранялись и как измерили эффект. Названия Kafka и параллельности сами по себе не объясняют ускорение.
Выбор должен следовать требованиям: журнал с retention, replay, partitions и независимыми группами часто ведёт к Kafka; сложная маршрутизация и task queues могут вести к RabbitMQ.
Брокеры отделяют производителей от обработчиков, буферизуют нагрузку и позволяют доставлять данные асинхронно. Kafka особенно подходит для долговременного журнала событий и независимых читателей.