Обычно меня сложно забайтить в интернете. Но на выходных я прочитала пост про подключение сервиса к Кафке, и не смогла пройти мимо. Автор описал типичную для меня ситуацию, когда команде нужно заказать новый топик у платформенной команды, и это делает аналитик. Кратко, там было негодование, что аналитик должен предоставить всю техническую инфу, да еще и в Excel: Аналитик, который внезапно должен: • посчитать объёмы сообщений, • определить количество топиков, • выбрать число партиций, • решить, сколько реплик и на каких брокерах, • и аккуратно раскрасить заявку по цветам в Excel-шаблоне. ... Аналитик как высокооплачиваемая секретарша с навыками Excel-дизайнера ... Аналитик подписывается под количеством партиций, хотя его экспертиза заканчивается на логике домена и бизнес-процесса. И тут у меня просто упало забрало, и я написала кучу комментов 😂 Если мы говорим про бизнес-аналитика, то у меня нет возражений. Речь про системных. Автор пишет, что таким образом платформа сбрасывает ответственность с себя на аналитика. Тут я в корне не согласна. Платформенная команда отвечает за работоспособность кластера Кафки. Реплики и брокеры — да, их зона ответственности. Но они не должны считать нашу нагрузку и определять нам топики 🤯 Топики — это вообще логическая группировка, разделение сообщений по топикам зависит только от наших сценариев. Например, у нас создание заказов. Мы можем все события создания и изменения заказов класть в один топик, а можем создание — в один, изменение — в другой. Смотря, как наш процесс обработки устроен. А нагрузка? Откуда платформенным инженерам знать, сколько данных у нас будет в одном сообщении и сколько таких сообщений наша система (или та, с которой мы интегрируемся) выдает? 🤔 С партициями тоже не так все просто. Партиции — это инструмент горизонтального масштабирования. Количество партиций можно приблизительно посчитать исходя из требуемой пропускной способности, но только команда разработки может знать, нужно им это или нет. Например, событий немного, но нам нужен строгий порядок абсолютно всех событий. Мы можем завести одну партицию, гарантировать себе порядок, а масштабирование нам не нужно. При выборе количества партиций желательно ориентироваться на число консьюмеров, которые их будут обрабатывать. Например, мы бахнем 30 партиций, а больше 3-х инстансов консьюмера поднимать не планируем, ресурсов нет. С точки зрения скорости это будет то же самое, что мы из 3-х партиций читали бы. Если нагрузка вырастет, мы сможем увеличить число партиций, а вот уменьшить их число нельзя. Слишком много партиций может вызывать медленную работу брокеров из-за обилия метаданных: какой брокер является лидером для этой партиции, где реплики и т. д. Если нет особых вводных, можно начать со стандартных 3-х партиций. Сюда же и retention policy: платформенная команда не знает, нужен нам стандартный подход с 7-ми дневным хранением или мы хотим вообще никогда не удалять сообщения, схлопывая их по ключу (а так тоже делают в особых случаях, у меня есть опыт). ❗️ При этом я совершенно не считаю, что аналитик должен самостоятельно это все определять и нести единоличную ответственность! Конечно, нет! У нас же командная разработка: есть продуктовая команда, для которой аналитик фичу и проектирует. Мое мнение, что ответственность за технические решения в продукте несет продуктовая команда, а не платформа, соответственно такие вещи надо обсуждать с командой (разрабами, техлидами, QA): на груминге или другой встрече. Обсудим сценарии, нагрузку, требования, ограничения, как будем обрабатывать -> сформируем понимание по техническим аспектам. Если будем сомневаться, сходим к ребятам из платформы и проконсультируемся по конкретным вопросам. А потом уже заполним заявку на заведение топиков. Почему раскрашивание ячеек в Excel делает из кого-то секретаря мне тоже непонятно. У нас форма подачи заявки сделана через систему типа HelpDesk, и я много таких заявок заполняла как лид, не чувствуя себя при этом секретаре