For a single event bus, if earlier messages cannot be delivered and enter the retry loop (which according to docs lasts up to 24 hours), will later messages be blocked from delivery?

Put another way: is each message processed fully independently from all other messages? Or is there some sort of roughly FIFO behavior plus a concurrency limit?

Let's say none of my messages can't get delivered for whatever reason and all of them enter the retry loop, could I potentially end up with millions of messages being retried in parallel?

Looked through the official docs and searched online plus asked AI, could not find any info.

For a single event bus, if earlier messages cannot be delivered and enter the retry loop (which according to docs lasts up to 24 hours), will later messages be blocked from delivery?

Put another way: is each message processed fully independently from all other messages? Or is there some sort of roughly FIFO behavior plus a concurrency limit?

Let's say none of my messages can't get delivered for whatever reason and all of them enter the retry loop, could I potentially end up with millions of messages being retried in parallel?

Looked through the official docs and searched online plus asked AI, could not find any info.

• aws-event-bridge

• docs.aws.amazon.com/eventbridge/latest/userguide/… When an event isn't successfully delivered to a target because of retriable errors, EventBridge retries sending the event. You set the length of time it tries, and number of retry attempts in the Retry policy settings for the target. By default, EventBridge retries sending the event for 24 hours and up to 185 times with an exponential back off and jitter, or randomized delay. – Jatin Mehrotra Commented 2 days ago
• Please provide enough code so others can better understand or reproduce the problem. – Community Bot Commented yesterday

1 Answer 1

EventBridge is not FIFO.

When creating a target for a rule, you may specify the retry policy - but EventBridge doesn't provide any mechanism for limiting concurrency. Retries will not directly impact delivery of later messages.

However, the target which is associated with the rule may itself impose some sort of concurrency limit. In this case it's possible for retries to impact processing of later messages.

For example Lambda targets are invoked asynchronously. All asynchronous (InvocationType=Event) Lambda invocations are placed into an internal (non-FIFO) queue that triggers the function. If the function has a concurrency limit or the account-level concurrency limit is reached, it could easily be overwhelmed by retries and fail to process later events. Additionally since the async event queue and concurrency limits are both shared across all functions in the account, this could impact unrelated services.

Using EventBridge without well-defined retry policies and concurrency limits on the targets themselves can be quite dangerous. However since retry is implemented using exponential backoff and targets such as Lambda have account level concurrency quotas, millions is unlikely.