Where can a duplicate become a second effect?

Goal & mental model verified

Spring messaging integrations connect templates and listeners to broker-specific behavior. Kafka transactions can cover a read/process/write Kafka sequence; this does not universally make external database or HTTP side effects exactly once.

Worked example · design exercise synthesis

A PolicyIssued event may be redelivered. A consumer records a stable event ID and performs its database change atomically where feasible, avoiding a second business effect on retry.

Engineering decision synthesis

Use messaging to decouple timing and absorb work under explicit delivery rules. Choose the broker by ordering, routing, retention and operational requirements rather than a universal winner.

Pitfall & diagnosis synthesis

Acknowledging before durable processing can lose work; acknowledging afterward can allow redelivery. “Exactly once” must name the protected boundary, and poison-message retries need a finite outcome.

Improve & validate synthesis

Test a crash after the effect but before acknowledgement. Track lag, retries and dead-letter handling; verify deduplication with the actual transaction and broker configuration.