Задали практичные вопросы Алексею Коровкину, техническому руководителю бэкенда клиентского приложения Wildberries.
⏹️ В каких сценариях вы используете Kafka и какую роль она играет в архитектуре?
Kafka применяется в следующих случаях:
— для асинхронных интеграций между командами,
— общения микросервисов внутри проекта без жёстких зависимостей,
— реализации event-driven architecture,
— паттерна Saga — чтобы максимально избегать распределённых блокировок.
⏹️ Какие типовые нагрузки у ваших потоков?
Kafka хорошо справляется с высокими нагрузками за счёт горизонтального масштабирования. Ключевая возможность — перечитывание топика с любого смещения (offset). Чтобы эта функция работала эффективно, критически важно правильно настроить Retention Policy— политику хранения сообщений в топике.
⏹️ Как вы подходите к дизайну топиков?
Дробление строго по доменной области не всегда оправдано — домен может быть большим и содержать очень разные сущности. Самый надёжный и универсальный подход — разбивать топики по типам событий.
⏹️Как вы выбираете ключ партиционирования (значение, по которому сообщения распределяются по партициям одного топика)?
Kafka гарантирует порядок сообщений только внутри одной партиции (логического сегмента топика, который обрабатывается независимо). Если для сущности критична строгая последовательность статусов — используем идентификатор сущности как ключ партиционирования. Если порядок не важен — оставляем дефолтное поведение для равномерного распределения нагрузки по консьюмерам (компонент, который читает и обрабатывает сообщения из топика).
⏹️ С какими проблемами вы сталкивались из-за неудачного выбора топиков?
Основная проблема возникает, когда в топике есть сущности, которые нельзя обработать идемпотентно (повторная обработка того же сообщения не приводит к изменению результата). В таком случае сдвиг offset приводит к ошибкам, и консьюмер не может продолжить корректную работу.
⏹️Какие гарантии доставки вы используете и почему?
Используем at-least-once — самый универсальный и безопасный вариант. Он исключает потерю сообщений (в отличие от at-most-once), а exactly-once слишком дорого стоит для брокера и всё равно не защищает от дублей при падении и перезапуске консьюмера.
⏹️Как вы работаете с дублями сообщений?
С самого начала проектируем идемпотентную обработку: либо бизнес-логика безопасно обрабатывает дубли, либо на стороне консьюмера храним ключ идемпотентности сообщения, чтобы избежать повторной обработки.
⏹️Как вы работаете с порядком событий и консистентностью?
Нарушение порядка — всегда признак проблемы в отправителе и повод для рефакторинга. Если это всё же происходит — отправляем событие в Dead Letter Queue (DLQ) на ручной разбор. «Силовое» переключение статуса маскирует проблему и часто приводит к трудноуловимым багам.
⏹️Какие метрики Kafka-консьюмеров для вас самые важные?
Самая критичная метрика — consumer lag (отставание консьюмера — разница между последним записанным и последним прочитанным смещением). Она сразу сигнализирует и о необходимости масштабирования, и о проблемах на стороне консьюмера.
⏹️Какие главные уроки вы вынесли из эксплуатации Kafka? Что бы сделали иначе?
Kafka — мощный, но не универсальный инструмент. Главные ошибки, которых стоит избегать:
— использование как замены базы данных;
— превращение в шину для синхронных RPC-вызовов;
— игнорирование ключей партиционирования;
— создание топиков без предварительного дизайна.
А какие вопросы по Kafka чаще всего возникают у вас в проектах?
👆 Пишите в комментариях — обсудим реальные кейсы!