mayton2019

Твоя задача может быть решена конфигурацией consumers вот как тут пишут https://www.baeldung.com/kafka-send-data-partition

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

В самом вопросе есть какой-то конфликт интересов. С одной стороны сессии БД надо экономить.
Тоесть нужно их закрывать. С другой стороны реакция на это сообщение в БД должна быть быстрой.

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

Я-бы еще этот вопрос рассмотрел в суточной нагрузке. Если например событие с кафки приходят
от кассовых аппаратов то их надо обработать обязательно в течение дня. Тоесть БД должна быть
открыта всегда. Ну а на ночь можно изменить режим работы косньюмеров и сделать их более
вялыми и дать возможность ночным джобам поработать в БД спокойно.

При расчете аналитики (min/max/avg) и прочих оконных функций сам алгоритм имеет лаг.
Тоесть ты должен понимать что за 1 мс ты можешь анализировать данные в прошлом за окно
размером к примеру в 100мс.

Нельзя выводить точную аналитику на основе мгновенного значения.

На производительность кафки влияет 4 сущности. Конфиг брокера, продюсера, консюмера и message configuration.
Очень сложно разбираться в том что у тебя происходит на основании такого странного теста. Скажи
сколько времени ты ждал этого загадочного listener. Как ты ждал. В какой лог смотрел. Почему
ты вообще решил что это проблема. Может продюсер ничего не производит. Короче дай картину
происходящего более подробную.

Объем данных - терабайт в день. 90 МБ/с траффика в пике.
Скорость ответа сервисов и мгновенная запись не важна, важно записать данные.

Между первым и вторым сервисом можно поставить Kafka. Это позволит смягчить ситуацию частичной
недоступности пишущего сервиса. Я здесь далее по топику предполагаю что Kafka и Cassandra - это облачные
решения которые в приципе не падают. А если и падают то очень редко и по крайне жестким авариям датацентров.

В этом случае в качестве точек сбоя можно просто рассматривать два ваших микросервиса.

Еще вариант. Вообще убрать пишущий микро-сервис. Я не знаю как в кассандре. Но в bigdata есть огромное
число т.н. коннекторов. Это что-то типа драйвера который позволяет писать стриминг в базы и наоборот.
Например есть коннектор который пишет сразу из Kafka в таблицы Databricks. Скорее всего для кассандры
тоже есть нечто подобное. Мне кажется с коннектором архитектурно получается проще.

Сравнительно недавно в Кафку завезли новый стандарт кворума на основе Raft-протокола. Это означает что Смотритель зоопарка будет скоро не нужен и его можно будет выкинуть нафик. А все ноды Кафки будут решать кворумные вопросы самостоятельно.

Автор не правильно формулирует задачу.