advanced
Exactly-once как practical trade-off
Обсуждайте exactly-once как scoped guarantees плюс idempotent side effects, а не magic end-to-end safety across every external system.
Настоящий exactly-once end-to-end через брокеры, БД и сторонние API нереалистичен без согласованности на каждом слое. В production стремятся к эффективному exactly-once: at-least-once плюс идемпотентные consumer, transactional outbox или дедупликация в заданной области.
Транзакционный produce/consume Kafka в одном кластере — ограниченная гарантия: она не дедуплицирует отправку email или вызов payment API. Укажите scope: порядок в partition, транзакция БД, окно idempotency key.
На интервью: уточните при «нужен exactly-once», какой инвариант нельзя нарушить, и предложите at-least-once с идемпотентностью или outbox для этого инварианта.
Типовые ошибки: exactly-once в маркетинге без границ; игнор дубликатов побочных эффектов вне брокера; транзакционные накладные расходы без оценки необходимости; смешение commit offset и завершения бизнес-операции.
Чеклист:
- Назовите инвариант, который нельзя дублировать.
- Выберите семантику доставки только для этого scope.
- Добавьте идемпотентность или outbox где нужно.
- Задокументируйте, что гарантия не покрывает.