Message brokers are built to survive failure, not to prevent it. Retries, consumer crashes, lock expiration, scaling events, and recovery workflows are signs of properly working brokers, but they all have one important consequence: duplicate message delivery. Duplicate messages are not an error condition; they are an inherent feature of reliability.

This session reframes idempotency as a first‑class architectural concern rather than a defensive coding trick. Instead of asking how to avoid duplicates, we explore how reliable messaging systems work, why duplicate delivery is unavoidable, and how to design message consumers that make duplicates harmless, observable, and auditable. We break down the common sources of duplicate delivery and walk through practical design patterns that turn at‑least‑once delivery into safe outcomes. Finally, we connect idempotency to replay safety and auditability. Systems that truly handle duplicates well can be safely reprocessed during incident recovery, data fixes, or regulatory audits. And all this without fear of double charging, duplicate provisioning, or inconsistent state.

You will leave with a clear understanding of reliable messaging, concrete design patterns that can be applied immediately, and a checklist for building message‑driven systems where duplicate messages are expected, intentional, and safe.