Kafka любят продавать как «надёжную магию»: положил событие — и дальше всё само. Но в реальной distributed-рут

Kafka любят продавать как «надёжную магию»: положил событие — и дальше всё само. Но в реальной distributed-рутине магии нет. Есть повторная обработка сообщений, и именно она тихо ломает сервисы, если о ней вспоминают только после инцидента.

Непопулярное мнение: retry — это не страховка, а отдельная зона риска. Сообщение может прийти ещё раз не потому, что Kafka «подвела», а потому что consumer не успел зафиксировать offset, упал на середине или словил временную ошибку. И вот у вас уже дубли, повторные списания, двойные уведомления и ночной созвон, который никто не планировал.

Здоровый подход тут скучный, зато рабочий: считать обработку не «один раз и навсегда», а делать её идемпотентной, заранее думать про DLQ, ограничивать бесконечные ретраи и явно решать, что считается успехом. 🧩

В distributed-командах это особенно заметно: меньше героизма, больше прозрачных правил. И Kafka это как раз тот случай, где рутина спасает лучше, чем надежда.