Коротко о статье
Клиент нажимает «Оплатить». Дальше платёж должен списать деньги, антифрод должен его проверить, бухгалтерия отразить, а клиент получить пуш. Если сервис оплаты будет по очереди вызывать всех остальных, одно медленное звено остановит всю цепочку. Поэтому в банках и платёжных сервисах события обычно пишут в Kafka, а каждая система читает их в своём темпе.
Разберём, как Kafka устроена внутри, что на самом деле значат гарантии доставки, и два приёма, без которых в финтехе не обходится ни одна интеграция: outbox и идемпотентность. В конце есть три вопроса для самопроверки.
Как устроена Kafka
Представьте журнал, в который можно только дописывать. Каждое событие получает порядковый номер (offset) и остаётся в журнале, даже когда его прочитали. Удаляются события по сроку хранения (по умолчанию семь дней) или по объёму. Это главное отличие от классической очереди, где сообщение исчезает после обработки.
| Понятие | Что это |
|---|---|
| Топик | Именованный поток событий одного типа, например payments |
| Партиция | Часть топика, отдельный журнал со своими номерами событий |
| Брокер | Сервер Kafka, хранит партиции. Кластер состоит из нескольких брокеров |
| Продюсер | Сервис, который пишет события в топик |
| Потребитель | Сервис, который читает события и сам помнит, на каком номере остановился |
Каждую партицию хранят несколько брокеров (фактор репликации, обычно 3). Один из них ведущий, остальные копируют за ним. Если ведущий падает, его место занимает реплика, которая успевала за ним. Метаданные кластера с Kafka 4.0 хранит встроенный протокол KRaft, ZooKeeper больше не нужен.
Партиции и порядок сообщений
Вот где ошибаются чаще всего. Kafka гарантирует порядок только внутри одной партиции. Если в топике шесть партиций, события в целом по топику придут в произвольном порядке.
Для платежей это важно: «создан» и «отменён» по одному платежу должны обрабатываться строго друг за другом. Решение простое: у сообщения есть ключ, и все сообщения с одинаковым ключом попадают в одну партицию. Ключом делают идентификатор счёта, клиента или платежа.
Группы потребителей и масштабирование
Потребители объединяются в группу, и Kafka делит между ними партиции: каждую партицию внутри группы читает ровно один потребитель. Шесть партиций и три экземпляра сервиса значит по две партиции на каждого. Если запустить восемь экземпляров, двое будут простаивать. Отсюда правило: число партиций задаёт потолок параллелизма.
Разные группы читают топик независимо. Антифрод и сервис уведомлений могут читать одни и те же платежи, каждый со своей скоростью и со своими номерами прочитанных событий.
Когда потребитель падает или добавляется новый, группа перераспределяет партиции (ребалансировка). Во время неё чтение ненадолго останавливается. Главная метрика здоровья здесь отставание потребителя (consumer lag): насколько последний прочитанный номер отстаёт от последнего записанного. Растущий lag означает, что обработка не успевает за потоком.
Гарантии доставки: at-most-once, at-least-once, exactly-once
| Гарантия | Что может случиться | Когда подходит |
|---|---|---|
| At-most-once | Сообщение потеряется, но не повторится | Метрики и логи, где потеря одной точки не страшна |
| At-least-once | Сообщение не потеряется, но может прийти дважды | Большинство бизнес-событий при идемпотентном обработчике |
| Exactly-once | Ровно одна обработка внутри Kafka | Цепочки «прочитал, посчитал, записал в другой топик» |
Чтобы не терять сообщения при записи, продюсер ждёт подтверждения от всех синхронных реплик (acks=all), а в топике задают min.insync.replicas=2. Идемпотентный продюсер включён по умолчанию в современных версиях: при повторной отправке после сетевого сбоя брокер отбросит дубль.
С exactly-once есть важная оговорка. Транзакции Kafka работают, пока данные ходят между топиками. Как только обработчик списывает деньги во внешней базе или вызывает API банка-партнёра, гарантия заканчивается. Там нужна идемпотентность на вашей стороне.
Кейсы финтеха: outbox и идемпотентность
Outbox: запись в базу и событие без рассинхрона
Сервис сохраняет платёж в PostgreSQL и отправляет событие в Kafka. Если база записала, а отправка упала, остальные системы о платеже не узнают. Если наоборот, по Kafka поедет платёж, которого нет в базе.
Паттерн outbox решает это так: в той же транзакции, что и платёж, в таблицу outbox пишется событие. Отдельный процесс (или Debezium, который читает журнал изменений базы) забирает события из таблицы и отправляет в Kafka. Запись в базу и событие становятся атомарными, а доставка превращается в at-least-once.
Идемпотентный потребитель: дубли не страшны
При at-least-once одно событие может прийти дважды. Для уведомления это лишний пуш, для списания это двойное списание. Поэтому у каждой операции есть уникальный ключ (идентификатор платежа), а потребитель перед обработкой проверяет, не обрабатывал ли его раньше. На практике это уникальный индекс в таблице обработанных операций: повтор просто упадёт на ограничении и будет пропущен.
Где ещё Kafka в финтехе
- Антифрод в потоке. Правила и модели проверяют операцию, пока она ещё не подтверждена.
- Выгрузка изменений из базы. Изменения таблиц передаются в хранилище данных и поиск без ночных выгрузок.
- Уведомления. Один поток событий, несколько каналов: пуш, почта, SMS, каждый в своей группе потребителей.
- Сверка. События партнёров и внутренние события сравниваются по ключу операции, расхождения уходят на ручной разбор.
Самопроверка: три вопроса по Kafka
Выберите ответ, сразу увидите разбор. Ничего не отправляется и не сохраняется.
Это разминка. В экспресс-квизе вопросы подбираются под ваш стек.
Как рассказывать про Kafka на собеседовании
Интервьюеру мало услышать определения. Ему интересно, понимаете ли вы, что будет при сбоях. Хороший ответ строится вокруг трёх вопросов: что произойдёт, если упадёт брокер; что, если упадёт потребитель посреди обработки; как вы не потеряете и не задублируете операцию.
Если у вас был реальный опыт, расскажите его с цифрами: сколько событий в секунду, сколько партиций, какой был lag и что вы с ним сделали. Такой рассказ стоит вынести и в резюме. Как упаковать его в отклик, мы разбирали в статье про сопроводительное письмо в IT.
Вопросы и ответы
Чем Kafka отличается от RabbitMQ?
Kafka хранит сообщения как журнал: после чтения они остаются на диске до истечения срока хранения, и их можно перечитать. Классическая очередь RabbitMQ удаляет сообщение после подтверждения. Kafka удобнее для потоков событий и нескольких независимых потребителей, RabbitMQ для маршрутизации задач между воркерами.
Гарантирует ли Kafka порядок сообщений?
Только внутри одной партиции. Чтобы все события одного счёта или заказа шли по порядку, отправляйте их с одинаковым ключом: сообщения с одним ключом попадают в одну партицию.
Можно ли получить exactly-once в Kafka?
Внутри Kafka да: идемпотентный продюсер и транзакции позволяют прочитать, обработать и записать результат ровно один раз. Если обработчик пишет во внешнюю базу или вызывает внешний API, нужна идемпотентность на стороне получателя, например проверка ключа операции.
Сколько партиций делать в топике?
Столько, сколько потребителей в группе вам понадобится при пиковой нагрузке, с небольшим запасом. Партиции можно добавить позже, но тогда ключи начнут попадать в другие партиции и порядок для них на время нарушится.
Нужен ли ZooKeeper для Kafka в 2026 году?
Нет. Начиная с Kafka 4.0 ZooKeeper не поддерживается, метаданные кластера хранит встроенный протокол KRaft. Вопросы про ZooKeeper на собеседованиях остаются, но в основном про миграцию старых кластеров.
Что спрашивают про Kafka на собеседовании?
Чаще всего: как устроены партиции и группы потребителей, что будет при падении потребителя, как не потерять и не задублировать сообщение, как связать запись в базу и отправку события (outbox), как мониторить отставание потребителей.
Другие темы для подготовки: теоретические задачи System Design.
От теории к практике
Пройдите квиз по своему стеку, соберите пет-проект с очередью сообщений и проверьте, как вы объясняете архитектуру, на пробном собеседовании. Регистрация бесплатная.
Что почитать дальше
Источники
Проверено 1 октября 2026 года. Примеры и самопроверку составила редакция IT Career Gym.
- Документация Apache Kafka: устройство топиков, репликация, гарантии доставки и транзакции
- Документация Debezium: захват изменений из базы данных и outbox