Создавал ли ты топики в Kafka

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

Не факт запуска команды, а понимание решений, которые принимаются в момент создания топика. Число партиций, фактор репликации и политика хранения потом меняются тяжело или не меняются вовсе, поэтому по ответу видно, работали вы с Kafka в бою или поднимали её только локально.

Как отвечать

Начните со способа. Топик заводят консольной утилитой, из кода через AdminClient, а в Spring-приложении бином NewTopic, который создаст KafkaAdmin при старте:

kafka-topics.sh --create --topic orders \
  --bootstrap-server kafka:9092 \
  --partitions 12 --replication-factor 3

Дальше про сами параметры, это и есть содержание ответа:

• партиции задают предел параллелизма: потребителей в группе больше, чем партиций, работать не будет, лишние простаивают. Увеличить число партиций можно, уменьшить нельзя;
• порядок гарантируется только внутри партиции, а партицию выбирает хеш ключа. Значит ключ берут по сущности, для которой порядок важен;
• фактор репликации на бою три, вместе с min.insync.replicas равным двум и acks=all у продюсера;
• хранение: retention.ms и retention.bytes для потока событий, cleanup.policy=compact для топика состояния, где нужна последняя версия по ключу.

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

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

Добавляют партиции живому топику и ломают порядок. Ключи разъедутся по новой раскладке, и события одной сущности окажутся сразу в двух партициях.

Второе: ставят acks=all и считают надёжность обеспеченной. При факторе репликации один это ровно одна копия, и падение брокера означает потерю данных.

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