Какой стек технологий используется, включая веб-фреймворк, микросервисную архитектуру, Kafka, RabbitMQ и Kubernetes

Что проверяют

Работали ли вы с этим набором руками и понимаете ли, зачем в одной системе и Kafka, и RabbitMQ. Сам список технологий интервьюер знает, ему важны связи между ними. Следом обычно спрашивают, как вы гарантируете, что сообщение не потеряется и не обработается дважды.

Как отвечать

Разложите стек по ролям:

• веб-фреймворк: FastAPI или Django, синхронное взаимодействие сервисов по HTTP или gRPC там, где нужен немедленный ответ;
• Kafka: распределённый журнал. Сообщения лежат в партициях и хранятся по retention, их можно перечитать. Порядок гарантирован только внутри партиции, поэтому ключ выбирают по сущности, например order_id. Масштабирование через consumer group, клиенты confluent-kafka или aiokafka;
• RabbitMQ: классический брокер с exchange (direct, topic, fanout) и очередями. Сообщение удаляется после подтверждения, есть маршрутизация, dead letter exchange и prefetch для контроля нагрузки. Клиент aio-pika, поверх RabbitMQ часто работает Celery;
• Kubernetes: Deployment, Service, ConfigMap и Secret, readiness и liveness пробы, горизонтальное масштабирование через HPA.

Типичное разделение: Kafka для потоков доменных событий, которые читают несколько сервисов, RabbitMQ для очередей задач и команд с гибкой маршрутизацией.

Покажите понимание надёжности: доставка обычно at-least-once, значит обработчики должны быть идемпотентными. Чтобы запись в базу и публикация события не разошлись, используют transactional outbox. Для потребителей важен graceful shutdown: под получает SIGTERM и должен дообработать текущее сообщение и зафиксировать offset.

Где спотыкаются

Сводят разницу к «Kafka быстрее». Ключевое отличие в модели: журнал с перечитыванием против очереди с удалением после подтверждения.

Коммитят offset до обработки или полагаются на автокоммит, и при падении посреди обработки сообщения теряются. Если же коммитить после обработки, возможны повторы, и без идемпотентности это двойные списания.

Делят одну базу между микросервисами. Формально сервисов много, фактически это распределённый монолит, где любая миграция может сломать соседа.