What problems arise from redelivering events?

With event redelivery (which happens often in EDA), the main problem is duplicate processing and broken data consistency. Below are the key risks and how they are solved:

#1. Duplicate actions

The same event can arrive twice because of network failures or a broker resending it. Example: the payments service receives two identical PaymentReceived events → a double charge or a duplicate record. Solution: idempotency: check event_id before processing, store processed identifiers.

#2. Broken event order

Events can arrive in the wrong order, especially when processed in parallel. Example: "Order canceled" arrives before "Order created". Solution: store version (or timestamp), order events before applying them.

#3. Loss of causality

If events are delivered repeatedly or with a delay, a consumer may apply a stale state. Example: an old "OrderUpdated" overwrites a newer "OrderShipped". Solution: use versioning and optimistic locking on updates.

#4. Consumer overload

Repeats can add extra load on services, especially with retries from the broker. Solution: limit the number of retries, use a dead-letter queue (DLQ).

#5. Side effects

On repeated processing, emails, push notifications, and transactions can be sent again. Solution: move side effects into a separate layer that checks whether it was already sent.

Summary:

Redelivery is a normal occurrence in EDA, but without idempotency, versioning, and accounting for event order, it leads to duplicates, inconsistency, and chaos in the data.