Kafka на собеседовании системного аналитика

Зачем SA знать Kafka

Kafka — стандарт асинхронной интеграции в РФ. Любой современный enterprise-стек использует Kafka для events. Системный аналитик пишет ТЗ на интеграцию через Kafka — нужно понимать, что описать: топики, формат, партиции, гарантии.

Главная боль без понимания Kafka — SA пишет в ТЗ «отправлять события в Kafka» — без указания топика, формата, ключа партиционирования, retention. Команда придумывает сама, через год миграция превращается в катастрофу.

На SA-собесе в банке/телекоме спросят базовые концепты Kafka. Глубоких internals не ждут — это уровень SA.

Базовые понятия

Топик — именованный поток событий. Не очередь — журнал (log). Сообщения хранятся, не удаляются после чтения.

Партиция — единица параллелизма топика. Топик = N партиций. Внутри партиции порядок строгий, между — нет.

Producer — пишет сообщения в топик. Может задавать ключ → hash определяет партицию (одинаковый ключ → одна партиция → строгий порядок).

Consumer — читает сообщения. Объединяются в consumer groups: партиции делятся между consumer'ами в группе.

Offset — позиция consumer'а в партиции. Хранится в Kafka.

Retention — срок хранения сообщений в топике (дни, недели). После — удаляются. Альтернатива — log compaction (хранится последнее значение по ключу).

Producer и доставка

acks (уровень подтверждения):

• 0 — не ждать (можно потерять)
• 1 — ждать leader'а партиции
• all — ждать all in-sync replicas (надёжнее)

В критичных топиках — acks=all + min.insync.replicas=2.

Idempotent producer — не создаёт дублей при retry. Стандарт включён по умолчанию (3.0+).

Transactional producer — атомарная запись в несколько топиков.

В ТЗ для SA: «Producer пишет с acks=all, гарантия доставки — at-least-once» (или exactly-once для критичных).

Consumer и offsets

Auto-commit: Consumer периодически коммитит offset. Опасно — может закоммитить раньше, чем обработал.

Manual commit: Коммит после успешной обработки. Безопаснее, но дороже latency.

Rebalance: при добавлении/падении consumer'а партиции перераспределяются. Во время — все consumer'ы в группе ничего не делают (стоп-зе-ворлд). На больших группах болезненно.

Семантика доставки:

• At-most-once — 0 или 1 раз (auto-commit до обработки)
• At-least-once — 1+ раз, возможны дубли (стандарт, с idempotent consumer)
• Exactly-once — ровно 1 раз (transactional + idempotent sink)

В ТЗ: «Consumer commit после успешной записи в БД, гарантия at-least-once. Целевая БД должна быть идемпотентна по бизнес-ключу».

Schema Registry и контракты

Schema Registry хранит схемы сообщений. Producer регистрирует схему, в сообщение пишет только её ID. Consumer достаёт схему по ID.

Зачем: без registry разработчики Producer и Consumer должны договориться формате. Любое изменение → ломается consumer. С registry — schema evolution по правилам совместимости.

Совместимость:

• Backward — новый consumer читает старые данные
• Forward — старый consumer читает новые
• Full — обе стороны

В ТЗ описывать: формат (Avro/JSON Schema/Protobuf), стратегию совместимости, как добавляем поля, как уведомляем потребителей о breaking changes.

Что описать в ТЗ

Минимум для интеграции через Kafka:

• Топик: название, partitions, replication, retention, compaction
• Producer: acks, idempotent, transactional
• Schema: Avro/JSON, registry, compatibility mode
• Ключ партиционирования: что в key (для строгого порядка)
• Consumer: consumer group, commit-стратегия, поведение при ошибке
• Гарантии: at-least-once / exactly-once, idempotency на стороне sink
• Dead-letter: что делать с unprocessable messages
• Мониторинг: lag, error rate, message rate

Пример блока в ТЗ:

Топик: orders.events.v1
  Partitions: 12 (по hash user_id)
  Replication: 3
  Retention: 14 дней
  Schema: Avro, backward compatibility
  Producer: acks=all, idempotent

Consumer: dwh-loader
  Group: dwh-loader-prod
  Commit: после успешной записи в DWH
  Idempotency: UPSERT по event_id в DWH
  Dead-letter: orders.events.v1.dlq, manual review

Частые ошибки

Не задавать ключ партиционирования. Без key Kafka использует round-robin → события одного user могут идти в разные партиции в разном порядке. Если порядок важен — обязательно key.

Auto-commit на критичных данных. Перезапуск consumer между commit и обработкой → потеря.

Один большой топик с 1 партицией. Без партиций нет параллелизма. Минимум 3-6.

Полагаться на порядок между партициями. Гарантирован только внутри партиции.

Без schema registry. Любое изменение поля от producer ломает все consumer.

Большие сообщения в Kafka. Лимит 1 МБ по умолчанию. Большие файлы — в S3, в Kafka — ссылка.

Не описывать retention. Без retention топик растёт неограниченно. По дефолту 7 дней; для важных событий — больше.

Связанные темы

• REST API на собесе SA
• Kafka на собеседовании DE
• Webhook, polling, SSE и WebSocket
• Идемпотентность API на собесе SA
• Подготовка к собесу системного аналитика

FAQ

Kafka — это очередь?

Не совсем. Очередь удаляет сообщение после ack. Kafka — журнал: сообщения хранятся до retention, могут читаться много раз разными consumer-группами.

Kafka vs RabbitMQ для SA?

Kafka — стриминг событий, replay, высокий throughput. RabbitMQ — традиционная очередь с маршрутизацией, лучше для command-style RPC. На собесе SA в РФ Kafka доминирует.

Что такое consumer lag?

Разница между последним записанным offset и закоммиченным consumer'ом. Если растёт — consumer не успевает. Метрика для мониторинга в проде.

Как описать exactly-once семантику в ТЗ?

«Producer работает с idempotent + transactional. Consumer коммитит offset в той же транзакции, что и запись в БД. Целевая БД использует UPSERT по event_id».

Что такое compacted topic?

Топик с log compaction: вместо TTL хранится последнее значение по каждому ключу. Удобно для «текущего состояния» (latest user profile event).

Это официальная информация?

Нет. Статья основана на документации Apache Kafka, опыте интеграционных команд в РФ.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.