Kafka — это не магия, а распределённый журнал событий. Но даже у журнала есть грязный угол: повторная обработк

Kafka — это не магия, а распределённый журнал событий. Но даже у журнала есть грязный угол: повторная обработка сообщений у consumer’а.

Если consumer упал после чтения, но до фиксации offset, сообщение прилетит снова. И вот у вас уже не «надёжная доставка», а дежавю с побочкой: дубль в базе, повторный платёж, повторный пуш, повторный скандал. 📌

Технически проблема проста, организационно — токсична: система может быть корректной, а бизнес-эффект всё равно ломает доверие. Поэтому Kafka-логика без идемпотентности, дедупликации и внятной retry-стратегии — это не архитектура, а ставка на удачу.

Что обычно спасает:
— идемпотентные обработчики;
— хранение processed message IDs;
— аккуратная работа с offsets;
— отдельный retry/DLQ-контур;
— мониторинг повторов, а не вера в «ну, вроде не должно».

В атаках и инцидентах мелкий технический дубль быстро становится большим PR-минусом. Потому что пользователю всё равно, где сломалось. Ему важно, что сломалось дважды.