Почему выбрали Kafka
Что проверяют
Знаете ли вы Kafka изнутри и умеете ли обосновать её вместо обычной очереди. От java-кандидата ждут ещё и конкретики по клиенту: настройки продюсера и потребителя, поведение при ребалансе, что даёт spring-kafka поверх обычного клиента.
Как отвечать
Модель: топик разбит на партиции, сообщения хранятся заданное время, потребитель двигает offset сам. Отсюда всё остальное: повторное проигрывание истории, несколько независимых групп на один поток событий, масштабирование через партиции, порядок внутри партиции по ключу, надёжность через репликацию.
Причины выбора формулируйте через задачу: события нужны сразу нескольким сервисам, поток большой, историю надо уметь переигрывать после исправления обработчика. Если же нужна очередь заданий с приоритетами, отложенным запуском и подтверждением по одному сообщению, честнее сказать, что ближе RabbitMQ.
Конкретика по Java, которую ждут: KafkaTemplate и @KafkaListener, ручной коммит вместо автоматического, acks=all вместе с min.insync.replicas, идемпотентный продюсер, max.poll.records и max.poll.interval.ms под реальную длительность обработки, Kafka Streams, когда нужна агрегация на лету.
Где спотыкаются
Называют время жизни сообщения TTL. В Kafka это retention по времени или размеру, плюс отдельный режим уплотнения по ключу, оставляющий последнее значение. Термин из другого мира выдаёт пересказ чужой статьи.
Обещают строго однократную обработку без оговорок. Она работает внутри Kafka через транзакции и чтение подтверждённых записей, а на границе с базой данных нужна своя дедупликация по ключу события или запись offset в той же транзакции.
Масштабируют потребителей без оглядки на партиции. Лишние экземпляры в группе просто простаивают, а тяжёлая обработка прямо в слушателе рвёт сессию и запускает ребаланс, после которого партиции переезжают и часть сообщений обрабатывается повторно.