Exactly-once не отменяет бизнес-идемпотентность

Идемпотентность нужна, чтобы retry не превращался в повторный платёж, заказ или списание. Но exactly-once транспорта не гарантирует однократный эффект во внешней системе.

Документация Apache Kafka 4.3: producer idempotence включена по умолчанию без конфликтующих настроек и требует acks=all, retries>0, max.in.flight≤5. KIP-98 связывает records и offsets только через sendOffsetsToTransaction; consumer должен читать read_committed. Внешний платёжный API вне этой гарантии.

AWS Builders’ Library рекомендует caller-provided request ID для повторов одного намерения. На своей стороне я добавляю unique constraint, состояния IN_PROGRESS/SUCCEEDED и reconciliation неизвестного исхода.

Stripe ограничивает idempotency key 255 символами и может удалить его после того, как ключу исполнилось не менее 24 часов. После pruning старый retry станет новым запросом. Это контракт Stripe, не универсальный TTL.

#Java #Kafka #идемпотентность

👋 Добро пожаловать в Java && Management

Здесь — практические разборы Java/JVM, архитектуры, Kafka, эксплуатации и инженерного управления: первичные источники, актуальные релизы, диаграммы и выводы для решений.

Навигация:
• #Java — JVM, Spring и платформенные изменения
• #Kafka — очереди, события и идемпотентность
• #идемпотентность — retry, консистентность и надёжность
• комментарии — вопросы и разборы в связанном чате

Нужен независимый технический аудит Java/backend, инфраструктуры или интеграций?
→ https://krot.name/

Профили и кейсы: https://krot.name/profiles/