Расскажите про опыт работы с Apache Kafka
Что проверяют
Умеете ли вы тестировать асинхронную интеграцию. Синхронный вызов виден целиком, а здесь надо доказать, что сообщение ушло, доехало, обработалось один раз по смыслу и не потерялось при сбое.
Как отвечать
Сначала модель, коротко и без зубрёжки. Топик делится на партиции, ключ сообщения определяет партицию, порядок гарантирован внутри партиции, а не в топике целиком. Читатели объединяются в группу, партиция достаётся одному читателю группы, позиция чтения хранится как смещение. Сообщение не исчезает после чтения: оно живёт по настройке хранения, поэтому повторное чтение возможно.
Дальше ваша практика:
- как готовили данные: писали сообщения в топик из теста, читали результат из выходного топика;
- где брали брокер: контейнер в интеграционных тестах или общий стенд;
- что проверяли в самом сообщении: схему и типы, обязательные поля, ключ, заголовки, совместимость версий формата;
- негативные сценарии: битое сообщение, недоступный потребитель, повторная доставка, порядок при нескольких партициях, отставание при всплеске нагрузки;
- метрики: отставание группы как главный признак того, что обработка не справляется.
Обязательно скажите про ожидание с таймаутом и повторными попытками вместо паузы фиксированной длины: асинхронный тест на паузе нестабилен по определению.
Где спотыкаются
Меряют Kafka мерками обычной очереди и говорят, что потребитель забирает сообщение и оно удаляется. Удаление не связано с чтением, и это важно: повторное чтение с прошлого смещения штатный сценарий, который тоже надо тестировать.
Второе: ждут строгий порядок по всему топику. Порядок есть только внутри партиции, поэтому события одной сущности должны идти с одним ключом. Тест, проверяющий порядок на нескольких партициях, будет падать через раз.
Третье: не проверяют дубликаты. Доставка по умолчанию идёт по принципу «хотя бы один раз», значит обработчик обязан быть идемпотентным. Отдельный тест на повторную доставку того же сообщения эту проблему находит, а тест на паузе её прячет.