на эту тему не встречал, по самой кафке есть офигенная дока на официальном сайте

Если ордеринг не важен наверное?

а он и так не важен, поскольку даже в рамках одного топика никто не гарантирует порядок сообщений, только в рамках отдельной партиции

Да, по mesage key. Видимо по постановке задачи действительно не важен.

Блин, начали использовать кафку, чтобы сделать сложные процессы более отказоустойчивыми, в итоге сложность возрасла на порядок 🙁

Сижу только и думаю “а как это сделать через кафку, а как то сделать через кафку”

Как Ленин через десяток лет после революции

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

Просто изначально там был синхронный gRPC, который мог висеть по нескольку минут, но зато можно хоть тысячу запросов параллельно послать
А теперь чтение из очереди стало узким местом

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

ну распределенные отказоустойчивые системы всегда сложны

все имеет свою цену, возможно, вам хватило бы очереди на постгре:)

Пришло время и мне вкусить этого говна, похоже 🙂

Ну так то и grpc работал, когда нет никаких сетевых проблем

Но без гарантий чего-либо

На кафку хоть часть гарантий можно свалить

на самом дел вам ничего не мешает обрабатывать сообщения из одной партиции параллельно, при этом порядок и скорость их обработки могут быть произвольными
в кафке мера обработанных сообщений в партиции является оффсетом
оффсет - это просто число, сообщения с id меньше которого являются обработанными, а больше - необработанными
соответственно никто вас не обязывает коммитить оффсет для каждого сообщения
мы, например, храним для каждой партиции оффсеты в min heap и коммитим наибольший посследовательный оффсет из этого хипа после каждого обработанного сообщения
в итоге мы можем параллельно обрабатывать произвольное количество сообщений из партиции, при этом рискуем при падении лишь задублировать обработку тех сообщений, которые уже были обработаны, но не были закомичены

Это я понимаю, я как раз не хочу терять сообщений

Пока два варианта вижу
1. создать побольше партиций и побольше консумеров, и параллелить несколькими консумерами. Просто, но не факт, что эффективно
2. как-то обеспечивать идепмотентность запросов, которые сами по себе технически не идемпотентны сейчас, и читать батчами. Можно добавить таблицу с id запросов, чтобы не обрабатывать один запрос дважды, но одно это идемпотентным запрос не сделает, и если он сфейлился в процессе обработки, то, увы, я об этом уже не смогу сообщить дальше ожидающей стороне. Ну и это сложнее, особенно если учесть, что такое нужно будет провернуть в N сервисов потом

Если у вас есть ресурсы на горизонтальное масштабирование, то это самый простой сценарий точно.

А если у вас раньше синхронные запросы не обрабатывались идемпотентно, то может и тут не надо?