Сколько партиций и консюмеров обычно используется в Kafka топиках

Что проверяют

Понимаете ли вы, что число партиций это решение про параллелизм и порядок, а не значение по умолчанию из чьей-то статьи. И знаете ли жёсткое ограничение: внутри одной группы читателей больше, чем партиций, не бывает.

Как отвечать

Универсальной цифры нет, есть способ её получить. Партиция это единица параллелизма и единица порядка: порядок гарантирован только внутри партиции, и обрабатывать её в группе может ровно один консюмер. Отсюда правило: партиций берут не меньше, чем планируется консюмеров на пике, плюс запас на рост.

Считают от пропускной способности. Меряете, сколько сообщений в секунду вытягивает один продюсер и один консюмер, делите целевой поток на меньшее из двух и округляете вверх. Дальше проверяете здравым смыслом: партиций сильно больше сотни на топик уже стоит обосновать, они дают нагрузку на брокеры, дескрипторы и время ребаланса.

Про консюмеров скажите три вещи. Лишние сверх числа партиций простаивают, это не ускорение, а тёплый резерв на случай падения. Разные группы читают один топик независимо друг от друга. В Go один процесс держит партиции как отдельные горутины, поэтому число экземпляров сервиса и число обработчиков внутри него это разные величины.

Где спотыкаются

Масштабируются добавлением консюмеров в группу, упираются в число партиций и не понимают, почему половина подов ничего не делает. Смотреть надо на назначение партиций внутри группы, а не на количество реплик.

Увеличивают партиции на живом топике как быстрое лекарство. Ключи после этого раскладываются по остатку от нового числа, сообщения одного ключа начинают попадать в другую партицию, и порядок по ключу ломается. Уменьшить число партиций обратно нельзя вовсе.

Разгоняют обработку внутри консюмера, раздавая сообщения партиции по горутинам, и теряют сразу и порядок, и корректность коммита: смещение уходит вперёд раньше, чем обработаны предыдущие сообщения, и при падении они уже не повторятся.