А вот теперь о вкусном....
🔆 Ненадёжность «надёжных» доставок: идемпотентность как единственный реальный гарант
привет и спасибо, Андрей Бураков! :)

На своих воркшопах Андрей всегда погружает участников на те низкоуровневые операции над которыми ты сам обычно не задумываешься. На одном из таких воркшопов подробно разбирали гарантию "точно 1 раз". Оказалось, опять миф! Никто ничего нам не гарантирует, и всё надо делать самим и ручками (никогда такого не было, и вот опять!). Это подстегнуло меня углубиться в эту тему, после чего я и пришла к вам.
Ранее мы разобрали механизм работы брокера, теперь свяжем этот механизм с гарантиями.

📩 At-least-once delivery: Дубликаты как неизбежность
Что обещают: Сообщение будет доставлено как минимум один раз.

Реальность: При сбоях (падение консьюмера, таймауты подтверждения) брокер отправит сообщение повторно. Результат - неизбежные дубликаты.

Почему:
1. Подтверждение (ack) может не дойти до брокера из-за сетевых проблем
2. Консьюмер может обработать сообщение, но упасть до отправки подтверждения



📩 At-most-once delivery: Потери как плата за скорость
Что обещают: Сообщение будет доставлено не более одного раза.

Реальность: Сообщения могут теряться при любых сбоях. Консьюмер подтверждает получение ДО обработки, поэтому при падении во время обработки сообщение теряется навсегда.

Где используется: В сценариях, где потеря данных менее критична, чем дублирование (например, метрики, логирование).


📩 Exactly-once semantics: Маркетинг или реальность?
Что обещают: Каждое сообщение будет обработано ровно один раз.

Реальность: На практике это сложная комбинация нескольких факторов:
- Идемпотентность производителя - предотвращение дублирования отправки
- Транзакционные операции между потреблением и отправкой новых сообщений
- Идемпотентность консьюмера - ключевой элемент. Именно на потребителя вешается основная логика, поэтому гарантии брокера тут абсолютно вторичны. Это стало главным инсайтом для меня.

🆘 Проблемы exactly-once:
1. Огромные накладные расходы на производительность
2. Сложность реализации и отладки
3. Ограниченная поддержка в распределённых сценариях
4. Не защищает от логических ошибок в бизнес-коде


❗️Прежде чем выбирать этот вид, тщательно обоснуйте его выбор, убедитесь, что без него вы точно не можете!