Проверяет архитектурное мышление и способность обеспечить правильную доставку событий
Используют внешний idempotency key + хранение последних offsets/IDs в Redis/Postgres.
Каждое событие имеет уникальный ID, и консьюмер проверяет, было ли оно обработано.
Существует несколько стратегий:
Каждое сообщение имеет уникальный ID.
Потребитель делает:
SETNX event_id 1 → если OK → обрабатываем
если EXISTS → пропускаем INSERT ... ON CONFLICT DO NOTHINGID хранятся N часов, иначе память взорвётся.
Финальный результат = функция от входных данных.
Например:
выставление статуса → идемпотентная операция
запись агрегата с версией
Local LRU cache + persistent store.
Потому что мы обеспечиваем exactly-once на уровне side-effects, а не Kafka commit.