Почему выбрали Kafka
Что проверяют
Понимаете ли вы, что именно выбрали: Kafka это распределённый лог, а не очередь задач. Проверяют, отличаете ли вы её от брокера вроде RabbitMQ по модели работы, а не по популярности, и трогали ли клиент из .NET руками.
Как отвечать
Начните с модели. Сообщения пишутся в партиции топика и лежат там заданное время независимо от того, прочитал их кто-то или нет. Потребитель двигает свой offset сам, поэтому историю можно перечитать с начала, подключить второго независимого читателя или переиграть поток после исправления обработчика. Порядок гарантируется внутри партиции, а ключ сообщения определяет, в какую партицию оно попадёт.
Дальше причины выбора под задачу: одни и те же события нужны нескольким сервисам, требуется повторное проигрывание, поток большой, масштабирование идёт добавлением брокеров и партиций, надёжность обеспечивается репликацией.
Для .NET говорите конкретно: клиент Confluent.Kafka поверх librdkafka, схемы сообщений через Schema Registry с Avro, Protobuf или JSON Schema, потребитель живёт в фоновом сервисе приложения.
И сразу сравнение: RabbitMQ удобнее там, где нужны хитрая маршрутизация, подтверждение отдельных сообщений и очередь заданий, Kafka выигрывает на потоках событий, которые нужны многим и надолго.
Где спотыкаются
Повторяют про миллионы сообщений в секунду. Цифра ничего не значит без размера сообщения, батчинга, значения acks и числа реплик, а следующий вопрос будет как раз про настройки.
Говорят про гарантированную доставку без условий. Она собирается из acks=all, min.insync.replicas больше единицы и идемпотентного продюсера, а строго однократная обработка живёт только внутри транзакций Kafka: при записи во внешнюю базу нужен свой ключ дедупликации.
Забывают про группу потребителей. Автоматический коммит offset включён по умолчанию и при падении даёт либо потерянные, либо повторно обработанные сообщения, а число одновременно работающих читателей в группе ограничено числом партиций.