Свяжите каждый механизм с задачей: Kafka для событийного потока, gRPC или HTTP API для вызовов с ответом. Реальная система может использовать все варианты.
Consumers масштабируют по lag, скорости поступления и обработки, задержке и насыщению ресурсов. Предел полезного параллелизма группы связан с количеством партиций.
Да, можно вручную назначить партиции и управлять offsets без автоматической consumer group. Тогда распределение, сохранение прогресса и восстановление становятся задачей приложения.
Расскажите, для чего использовали брокер, какие гарантии ожидали и какие сбои обрабатывали. Kafka и NATS нельзя считать взаимозаменяемыми только потому, что оба передают сообщения.
Для Kafka уточняйте сообщения в секунду, байты в секунду, число партиций, retention и lag. Одного слова RPS недостаточно: запрос может содержать целый batch.
Это определяется топологией consumers и их group.id, а не просто числом дата-центров. Одна группа делит партиции, независимые группы читают поток независимо.
Утечку горутин в consumer ищут по росту их числа и повторяющимся стекам ожидания. Типичные причины — забытая отмена, заблокированный канал или незавершённый worker.
При ошибке БД нельзя подтверждать обработку пачки как успешную. Её нужно повторить или сохранить для восстановления; длительная обработка ограничена настройками consumer и протоколом группы.
Разделите роли интеграции: кто владел данными, кто инициировал передачу и как подтверждалась обработка. API, публикация и чтение Kafka могут сочетаться в одном процессе.
Опишите свою роль в решении: предложили вариант, исследовали риски, сделали прототип или участвовали в обсуждении. Не нужно приписывать себе единоличное внедрение командного инструмента.