Kafka на собесе любят не за «что это такое», а за то, где она ломает систему.

Kafka на собесе любят не за «что это такое», а за то, где она ломает систему.

Один из самых частых подводных камней — повторная обработка сообщений в consumer’е. Казалось бы: прочитал, обработал, подтвердил offset. Но в реальности между этими шагами легко получить дубликат, падение, retry loop или невалидное состояние в БД.

Что спрашивают на интервью:
1. Где именно у тебя идемпотентность?
2. Что будет, если consumer упал после записи, но до commit offset?
3. Как отличить transient error от permanent?

Хардкорный, но правильный ответ: Kafka сама не гарантирует «ровно один раз» в твоём бизнесе. Это твоя ответственность на уровне обработки.

Чек-лист сильного ответа:
- есть ли у сообщения уникальный key/id;
- можно ли безопасно повторить обработку;
- как устроен retry: сразу, с backoff, через DLQ;
- что происходит при rebalancing и повторном чтении;
- чем заканчивается ошибка: повтором, парковкой, алертом 🚨

Если на собесе просят «просто рассказать про Kafka», не уходи в теорию. Говори через фейлы, offset’ы и последствия для данных. Именно так оценивают middle/senior.