A pod restart between charging and committing the offset bills the customer twice

The guard is a uniqueness constraint. The tutorial's table is one column plus a timestamp: `event_id VARCHAR(255)` as the primary key, `processed_at TIMESTAMP NOT NULL DEFAULT now()`, and the database itself refuses to store the same event_id twice ^[9]. No branch in the listener has to be correct for that to hold. Where the ID comes from is the part that has to be right: it must be a stable ID set by the producer and carried in the payload, an eventId or an orderId, because a `UUID.randomUUID()` minted at consume time makes every redelivery look new and the whole scheme pointless ^[8]. The tutorial maps the row to a JPA `@Entity` with `@Id private String eventId` ^[10].

The failure being replaced is quiet. On redelivery `paymentService.charge(...)` runs a second time with no error and no stack trace, and what surfaces is a customer with two charges and a support ticket ^[5]. "The bug isn't in Kafka. It's an assumption that your consumer would ever see each event only once," the tutorial says ^[6]. There is nothing to catch, so the fix is not a try/catch; the operation has to be safe to run any number of times with the same result as running it once ^[7]. The tutorial's picture for the current state of `charge()` is a light switch, where every press changes the state, against an elevator button pressed five times for one elevator ^[11].

Whether the pattern transfers turns on atomicity. The tutorial states that two things must happen together or not at all, recording the event and performing the side effect, and the supplied text breaks off at that sentence ^[12]. If the work is a row in the same database as `processed_events`, one transaction covers both and the primary key is the whole guarantee. If the work is an HTTP call to a payment provider, the insert and the charge cannot share a transaction. Insert first, and a crash in between loses a charge. Charge first, and the customer is exposed to exactly the double charge the table was built to prevent. In that shape I would want the provider to accept an idempotency key of its own, with `processed_events` as a fast path only.

Every remedy in the excerpt sits on the consumer side: a producer-set event ID and a uniqueness constraint ^[13]. For a billing consumer that is the scope I would pick too, since the consumer is the component that can see the duplicate and owns the side effect. What the tutorial names as the trigger is ordinary operational traffic: a deploy, a scale-up, a pod restart ^[4].