RabbitMQ, Kafka, Azure Service Bus — all live in at-least-once land. Handlers written for "exactly once" can ship double orders, emails, and charges. Treat this as behavior, not a pre-deploy checklist bullet.
Minting random UUIDs only in the consumer is usually wrong. Keys belong on the producer side, tied to business rules — e.g. tenantId:orderId:CapturePayment. Don't default TTL to 24 hours either; if orders stay open for seven days, so should the key.
DB commit and event publish must be atomic. The outbox pattern helps: retries carry the same eventId so consumers can dedupe. "Publish first, DB second" can cause silent data loss on a night deploy.
Side effects — mail, payment, inventory — should run after the idempotency check. Poison messages shouldn't retry forever; after N attempts, DLQ and alert. One pre-deploy question is enough: "What if this message arrives twice?" The answer must be visible in code and tests.