Pattern 1: The Saga Pattern for Distributed Transactions
In a microservices architecture, a single business operation (like placing an order) may span multiple services: inventory, payment, shipping. If payment succeeds but shipping fails, you need to compensate — refund the payment, restore inventory.
EventBridge enables the Choreography-based Saga: each service listens for events and emits its own events. The Inventory Service listens for OrderPlaced, emits InventoryReserved. The Payment Service listens for InventoryReserved, emits PaymentProcessed. If the Shipping Service fails, it emits ShippingFailed, which triggers compensating transactions upstream.
This is powerful but complex to debug — there is no central coordinator. For complex sagas, consider AWS Step Functions (orchestration-based saga) instead, where a central state machine coordinates all steps.
Pattern 2: Cross-Account Event Routing
In large organizations, different teams own different AWS accounts. EventBridge supports cross-account event delivery natively.
# In the PRODUCER account: grant the CONSUMER account permission to receive events
aws events put-permission \
--event-bus-name "ecommerce-fulfillment-bus" \
--action "events:PutEvents" \
--principal "999888777666" \
--statement-id "AllowConsumerAccount"
The consumer account then creates a rule on its own default bus that routes events from the producer's bus. This enables a hub-and-spoke event architecture across an entire AWS Organization.
Pattern 3: Scheduled Events (EventBridge Scheduler)
EventBridge also functions as a cron replacement. You can create rules that fire on a schedule rather than in response to an event.
# Trigger a Lambda every day at 9 AM UTC
aws events put-rule \
--name "DailyReportRule" \
--schedule-expression "cron(0 9 * * ? *)" \
--state "ENABLED"
EventBridge Scheduler (a newer, separate service) extends this with one-time schedules, timezone support, and flexible time windows — useful for scheduling future events like "send a reminder email 24 hours after signup."
Production Checklist
Before deploying EventBridge in production, verify:
- [ ] DLQ configured on every rule target — failed deliveries must not vanish silently.
- [ ] CloudWatch metrics monitored — specifically
FailedInvocationsandThrottledRulesper rule. - [ ] Consumers are idempotent — at-least-once delivery means duplicate events are possible.
- [ ] Schema Registry populated — event contracts are documented and versioned.
- [ ] IAM least privilege — each rule's execution role has only the permissions needed for its specific target.
- [ ] Event bus resource policy — explicitly controls which accounts and services can put events.
A common senior-level interview question: "How do you handle duplicate event delivery in an event-driven system?" The answer has two parts: (1) EventBridge guarantees at-least-once delivery, not exactly-once. (2) Your consumers must be idempotent — processing the same event twice must produce the same result as processing it once. Common idempotency techniques include: using the event's id field as a deduplication key stored in DynamoDB with a TTL, using SQS FIFO queues with message deduplication IDs as a buffer before Lambda, or designing operations that are naturally idempotent (e.g., SET inventory = 10 is idempotent; DECREMENT inventory BY 1 is not).
Key Point: EventBridge is not a database. Events are not stored indefinitely — they are delivered and discarded. If you need event replay (re-processing historical events), use EventBridge Archive and Replay. You can configure an archive on any bus to retain events for a specified period (1 day to indefinitely), then replay a time range of archived events to any bus — invaluable for disaster recovery, debugging, and backfilling new consumers with historical data.