delivery-semanticslisted

# Delivery Semantics ## Purpose Decide which delivery guarantee a path needs, and place the acknowledgement so the code actually provides it. The guarantee is not a broker setting; it is the position of the ack relative to the side effect, plus whatever the application does about duplicates. The failure this prevents is the system designed against a guarantee nobody implemented: a team believes the platform gives "exactly-once", the handler is not repeat-safe, and the first rebalance during a slow poll charges a customer twice. The second failure is its mirror — a consumer that acknowledges first and silently drops work on every crash, which produces no error anywhere and is discovered by reconciliation months later. ## Workflow Java snippets are partial illustrations using Java 17 syntax, Kafka client 4.1 API and Jakarta Messaging 3.1 contracts, not complete consumers. Inspect resolved clients/provider, broker version, framework acknowledgement mode, transaction manager and durability/retention configuration. Existing project versions govern implementation; do not upgrade to fit a snippet. 1. **Name the side effect and where it lands.** Inside the same broker cluster, in a database, or across the network at a third party. That single fact decides everything below; a transaction cannot span a boundary it does not control. 2. **Locate confirmed progress relative to durable completion.** Acknowledging first opens a loss window; completing first opens a duplicate