Event Bus Retry Configuration: Avoiding Duplicate Writes Without Built‑in Idempotency

Answer to the Three Questions

1. Setting sendTimeout and retryCount only controls how many times the broker will attempt to deliver a message before giving up. They do not cause the broker to deduplicate or suppress a second delivery once the first attempt has timed out or failed. A message that was not acknowledged will be retried, potentially arriving multiple times at the consumer.
2. Vert.x 4.x does not expose any API that lets the broker automatically detect and drop duplicate deliveries. Exactly‑once semantics are therefore a responsibility of the application. The recommended pattern is to assign a globally unique identifier to each message, persist that ID in a durable store before performing the write, and skip the write if the ID has already been seen.
3. Yes. When a consumer processes a message successfully, it should reply via the supplied replyHandler (or by invoking reply() on the message). If the reply is received by the sender before the sendTimeout expires, the broker will not trigger a retry. If the consumer fails to reply in time, the broker will retry up to retryCount times, which can lead to duplicate writes unless idempotency logic is in place.

Practical Steps for Your Use‑Case

• Assign a Unique Message ID – Add a header such as msg-id containing a UUID or a monotonically increasing counter that is unique across the producer’s lifetime.
• Persist Processed IDs – Before performing the downstream write, query a lightweight, durable store (e.g., a Redis set, a database table, or a local file) to see if the msg-id has already been processed. If it exists, skip the write and simply reply to the sender.
• Atomic Write + ID Store – Wrap the write and the “mark as processed” operation in a transaction or atomic operation so that a failure between them cannot leave the system in an inconsistent state.
• Reply on Success – Immediately call message.reply(null) (or replyHandler.handle(null)) after the idempotency check and before the actual write. This guarantees the broker will not retry if the consumer has already handled the message.
• Configure Timeout and Retries Wisely – Keep sendTimeout short enough to avoid long blocking of the producer, but long enough to accommodate normal consumer processing time. Set retryCount to a small number (e.g., 1–2) to avoid excessive duplicate attempts; a value of 0 disables retries entirely but risks message loss on transient failures.
• Log and Monitor – Emit a log entry each time a retry occurs, including the message ID. This makes it easy to audit duplicate attempts and verify that idempotency logic is functioning.

When to Adjust Retry Settings

Changing retryCount or sendTimeout can reduce the number of duplicate deliveries, but it does not eliminate them. If your application tolerates occasional duplicate writes or can recover from them, you might keep the defaults. For strict exactly‑once guarantees, rely on the idempotency pattern above and keep retries minimal.

Diagnostic Question

To fine‑tune the recommendation, could you confirm whether your messages already carry a unique identifier header that can be used for deduplication?