At-least-once vs Exactly-once¶

Сравнения · Раздел03

Тип материала: инженерное сравнение; выводы зависят от требований и условий эксплуатации. Схемы и примеры иллюстративны.

Версии указаны в заголовках и связанных статьях. Численные показатели производительности не заявляются.

Критерии выбора¶

Критерий	At-least-once delivery + idempotent effect	Exactly-once contract в явной scope
Workload / architecture	Replayable processing с возможными duplicates	Atomic state/progress/output protocol supported resources
Consistency / transaction boundary	Effect один при durable dedup+atomic update+retention	Guarantee ограничена engine/transport/sink participation
Latency path	Retry/dedup/database overhead	Transaction/checkpoint/coordination/visibility cost
Throughput / scalability	Partition/target contention/dedup storage	Coordinator/snapshot/state/target limits
Operational complexity / cost	Inbox lifecycle/conflict handling/reconciliation	Protocol compatibility/timeouts/fencing/recovery ops

flowchart TB
  Replay[Replayable input] --> Duplicate[At-least-once delivery]
  Duplicate --> Inbox[Atomic dedup plus effect]
  Replay --> Engine[Supported engine transaction]
  Engine --> Kafka[Kafka or managed-state boundary]
  Inbox --> DB[One DB observable effect]
  External[External HTTP or Redis] -. own protocol required .-> Engine

Конкретные сценарии¶

Kafka→SQL consumer с atomic inbox+effect может дать один observable DB effect при повторной доставке. Kafka→Kafka transaction обеспечивает иной boundary. Flink→Redis требует versioned snapshots/recovery policy, checkpoint alone недостаточен.

Ограничения и восстановление¶

Нельзя выбирать по label без failure matrix. Physical handler invocation может повторяться при EOS state. Retention cleanup, wrong identity и external side effect нарушают assumptions. Ledger всегда сохраняет свой authoritative transaction protocol.

Как проверить выбор¶

Зафиксировать query/event mix, schema/payload, skew, working set/state, retention, target effect и допустимую stale-read policy. Проверять lost ACK, restart/rebalance, poison record, late correction и rebuild generation. Сравнивать TCO с одинаковыми durability/replication требованиями, включая engineering, maintenance и restore. Универсальный winner отсутствует.

Типичные ошибки проектирования¶

Сравнивать разные boundaries как одинаковую гарантию; игнорировать recovery и source retention; публиковать чужие latency/TPS как свои измерения; забывать target operations.

Вопросы на собеседовании¶

Когда стоит сочетать варианты? Когда они отвечают на разные уровни/нагрузки и contracts переходов определены. Дополнительный компонент добавляет ownership, lag, recovery и стоимость, поэтому нужна измеримая польза.

Практические упражнения¶

Составьте ADR для одного сценария: invariant, rejected alternative, failure matrix, recovery evidence и план честных измерений. Укажите, какие guarantees ещё UNKNOWN.