Подготовка к интервью
Разбирайте реальные вопросы, сверяйтесь с подробными ответами и готовьтесь по технологиям и компаниям.
Проверьте, насколько резюме подходит выбранной позиции, и получите рекомендации по улучшению.
Каталог
Kafka не гарантирует общий порядок между разными партициями и топиками. При отсутствии связанной записи событие лучше надёжно отложить и повторить после зависимости, а не терять или игнорировать FK.
Читать ответKafka делает акцент на сохранённом журнале событий, партициях и offsets, RabbitMQ — на маршрутизации и доставке через очереди. Это различие модели, а не правило «один быстрый, другой надёжный».
Читать ответДля PostgreSQL Debezium получает поток через logical decoding и replication slot, преобразует изменения строк в события и передаёт их в Kafka. Обычно сначала выполняется согласованный начальный snapshot.
Читать ответПокажите жизненный цикл заявки: событие входа, обработку каждым сервисом, промежуточные состояния и финальное решение. Конкретные топики и правила одобрения нужно брать из реального проекта.
Читать ответKafka прежде всего хранит распределённый журнал с offsets и повторным чтением, а RabbitMQ предоставляет маршрутизацию и очереди сообщений. Выбор зависит от модели потребления и требований, не только от скорости.
Читать ответЕсли commit offset выполнен до надёжной обработки, обычное продолжение группы пропустит сообщение. При сохранённом логе можно переобработать нужный диапазон offsets, контролируя дубликаты.
Читать ответНе подтверждайте предположение о FastAPI без фактов. Опишите прежний поток запросов и данных, а затем объясните, что изменилось после добавления событий и Kafka.
Читать ответТиповой поток: склад публикует изменения в Kafka, каталог обновляет модель чтения и кеш Redis, а frontend получает данные через API. Реальная схема и формула популярности зависят от проекта.
Читать ответRabbitMQ часто удобен для очередей рабочих задач и гибкой маршрутизации, Kafka — для сохраняемого потока событий с независимыми потребителями и replay. Выбор зависит от требований, а не только объёма.
Читать ответKafka хранит события в распределённом журнале, позволяя независимым потребителям читать и перечитывать поток. Её сильные стороны — масштабирование потока и replay, цена — эксплуатация и сложность контрактов.
Читать ответPush отправляет данные потребителю по инициативе брокера, pull позволяет потребителю запрашивать порции. Управление потоком нужно в обоих случаях; сама модель не определяет весь расход памяти брокера.
Читать ответВ обычном топике Kafka чтение всеми группами само по себе не удаляет сообщение. Его хранение определяется политикой retention или compaction, независимо от offsets потребителей.
Читать ответ