AWS EventBridge Lambda Event-Driven Architecture
In an event-driven design a service announces that something happened and does not know who cares. Amazon EventBridge is the router in the middle: producers put events on an event bus, and rules on that bus decide which targets receive each event. A single rule can send an event to more than one target, and they run in parallel.
This template shows an order service that publishes one event, and three AWS Lambda functions that react to it on their own. Adding a fourth reaction means adding a rule and a function. The producer does not change. It also shows the two safety nets most teams add: a dead-letter queue for events that could not be delivered, and an archive that keeps events so they can be replayed.
Scroll sideways to see the whole diagram
Start from this diagram and edit it on your own board.
By continuing, you agree to the Terms of Service and Privacy Policy, including sending images of your strokes, diagram labels and similar data to providers in the United States (Cloudflare, Inc. and TypeSafe AI, Inc.) for AI conversion.
What each part does
- Producer app
- Anything that has news to share, such as an order service. It sends events to the bus with the PutEvents API and does not know who receives them.
- Event bus
- Receives events and checks them against its rules. Each rule has an event pattern, a description of the events it wants, and up to five targets. An event that matches no rule is not delivered anywhere.
- Billing Lambda
- A target of one rule. It runs only for the events that rule matches, for example orders that need an invoice.
- Shipping Lambda
- A target of a second rule. It works on the same event independently of billing, and a failure in one function does not stop the other.
- Email Lambda
- A target of a third rule. In this diagram it is the target that has a dead-letter queue configured, to show that the setting belongs to one target and not to the bus.
- Dead-letter queue
- A standard Amazon SQS queue, set per target, which is why it is drawn next to Email Lambda. When EventBridge cannot deliver an event to that target after its retries, or an error means it should not retry (a missing permission, for example), the event goes here instead of being lost. A FIFO queue cannot be used. If the function receives the event and then fails, that is not an EventBridge delivery failure: it is handled by Lambda's own error handling, such as its retries and its own dead-letter queue or on-failure destination.
- Archive
- Stores events from the bus, optionally only those that match a pattern, for a number of days you choose (by default they are kept until you delete them). You can later replay a time range back to the same bus.
How an event flows
- The producer calls PutEvents to send an event to the event bus.
- EventBridge compares the event with the event pattern of every rule on the bus.
- Each rule that matches sends the event to its targets. Here three rules each invoke a different Lambda function, so the three functions work on the same event in parallel.
- If delivery to a target fails with an error that can be retried, EventBridge retries it. By default it keeps trying for up to 24 hours and up to 185 times, with exponential backoff and jitter.
- When EventBridge still cannot deliver to a target, it puts the event in that target's dead-letter queue, if one is configured. Without one the event is dropped. Errors raised inside a function after it has accepted the event are Lambda's to handle, with its retries and its own dead-letter queue or on-failure destination.
- In parallel, the archive stores the events that match its pattern. After a fix, you can replay a time range to the bus and the rules run again for those events.
When to use it
- Reacting to one business event, such as an order being placed, in several independent places: billing, shipping and email.
- Reacting to events from AWS services and SaaS partners without polling for them.
- Decoupling teams: a team publishes events as a contract, and others subscribe with rules of their own.
Common variations
Run a function on a schedule
EventBridge still supports scheduled rules, but AWS documents them as a legacy feature and recommends EventBridge Scheduler for time-based invocations. Scheduler offers cron and rate expressions, one-time schedules and its own retry settings.
Put a queue in front of a slow consumer
Make an SQS queue the target and let Lambda read from the queue. The queue absorbs bursts, and the consumer gets the retry behaviour of SQS and its own dead-letter queue.
Send events to another account or Region
A rule can target an event bus in another account or Region, so a central team can collect events from many places. For a bus in another account, the receiving bus needs a resource-based policy that allows the sending account, and the rule needs a role to send with.
Tune retries per target
Each target has its own retry policy: the maximum age of an event and the maximum number of attempts. Shorten them for work that is useless once it is late, and keep the dead-letter queue to inspect what failed.
Make it yours
Rename the producer after your own service, then write the event pattern for each rule. The names of the three functions are the next thing to replace.
Opens this diagram as a board you can edit.
By continuing, you agree to the Terms of Service and Privacy Policy, including sending images of your strokes, diagram labels and similar data to providers in the United States (Cloudflare, Inc. and TypeSafe AI, Inc.) for AI conversion.