Kafka редко ломает продукт прямо. Чаще — незаметно дублирует работу.
Если consumer получил сообщение, но не успел корректно подтвердить обработку, оно может прийти снова. Для команды это выглядит как «тот же заказ», «тот же платеж», «то же уведомление» — только уже во второй раз. В distributed system это не сбой, а особенность модели.
Что важно держать в голове:
1. Считать повторную доставку нормой, а не исключением
2. Делать обработку идемпотентной — чтобы повтор не менял результат
3. Явно продумывать, где ставить commit и что считать успешной обработкой
Чек-лист для consumer’а:
- есть ли у события уникальный ключ?
- безопасно ли повторить бизнес-операцию?
- что произойдет при падении между обработкой и ack?
- есть ли наблюдаемость: метрики, логи, алерты?
Kafka хорошо масштабирует поток. Но надежность появляется не в брокере, а в том, как вы проектируете обработчик. ⚙️
Voice & Proof
@VoiceProofPro
Kafka редко ломает продукт прямо. Чаще — незаметно дублирует работу.
Этот пост опубликован в Telegram-канале Voice & Proof. Подписаться можно по ссылке: @VoiceProofPro.