Articles
EventBridge Interview Questions: Filtering, Retries, Replay, and Delivery Failures
Prepare for EventBridge interviews with precise event patterns, partial send failures, target retries, DLQ evidence, and safe archive replay.
A producer receives HTTP 200 from EventBridge, but a customer never gets a receipt. The target's dead-letter queue is empty. The team concludes the notification service must be broken.
That conclusion skips several boundaries. The event might not have been accepted as expected, might not have matched the intended rule, might not have reached the target, or might have reached a target that later failed its business operation. Each possibility needs different evidence.
EventBridge interview answers become clearer when you follow one event through ingestion, matching, delivery, and processing. Retry policies and replay are useful only after you identify which boundary failed.
Evidence boundary: AWS documentation supports the platform facts linked below. The receipt-routing pattern, test matrix, and replay plan are original preparation exercises, not candidate reports or executed AWS tests. This article focuses on event buses and rule targets; Pipes and Scheduler have separate contracts.
For an early exercise, open Build Event Notification Engine. Add a missing receipt and explain which identifier would connect the producer's intent with the customer's eventual notification.
What does a successful PutEvents response prove?
Official fact: PutEvents processes entries individually, and a response can contain both successes and failures. Inspect FailedEntryCount and the corresponding entries rather than only the HTTP status. AWS also documents a surprising case: publishing to a nonexistent event bus can return 200 without increasing that failure count while the event is dropped. See sending events with PutEvents.
In the original receipt scenario, record the intended bus ARN, account, Region, application event ID, and per-entry result. Verify the bus exists as part of deployment checks. A familiar bus name in a configuration file is not evidence that the producer used the correct destination.
When a batch partially fails, preserve the mapping between each input and result. Retry eligible failed entries with bounded backoff and a stable application identity. Resending every successful entry too can create unnecessary repeated processing downstream.
An uncertain network outcome is different from a known failed entry. If the client lost the response, it may not know whether the event was accepted. Consumers should recognize repeated business intent rather than assuming a new EventBridge envelope always represents a new receipt to send.
How do you design a pattern that matches the intended event?
Official fact: Event patterns select events using their structure and values. Fields omitted from the pattern do not become implicit validation requirements. See event patterns.
The original requirement is: route completed retail payments to receipt processing. The producer uses source: com.example.checkout, detail-type: PaymentCompleted, and a detail object containing channel and amount. A narrow illustrative pattern is:
{
"source": ["com.example.checkout"],
"detail-type": ["PaymentCompleted"],
"detail": {
"channel": ["retail"],
"amount": [{"numeric": [">", 0]}]
}
}
This pattern is a routing decision, not complete payment validation. The target still needs to validate identifiers, supported schema versions, and business state. For example, a positive amount does not prove the payment settled or that the event came from an authorized business workflow.
Official fact: EventBridge supports numeric and other comparison operators, with differences between event-bus and pipe support. See comparison operators. Do not substitute a quoted numeric string for a JSON number and assume the same comparison applies.
Official fact: Ordinary string matching is case-sensitive, field nesting matters, and TestEventPattern can test a pattern against samples. See pattern syntax.
Use this original match matrix before changing production routing:
| Sample change from the intended event | Expected result for this pattern | Why it belongs in the test set |
|---|---|---|
| Correct source, type, retail channel, numeric amount 25 | Match | Positive control |
Paymentcompleted instead of PaymentCompleted | No match | Case regression |
channel moved outside detail | No match | Nesting regression |
Amount is string "25" | No match | Type regression |
| Numeric amount 0 | No match | Boundary value |
| Additional unrelated detail field | Match | Extra fields are not automatically forbidden |
The expected outcomes are reasoned from the documented pattern; they are not claimed as an AWS test run. Execute the samples with the actual pattern-testing tool during implementation and save the results with the policy change.
Why might a matching rule still fail to deliver?
The rule's presence is not enough. Verify that it is enabled on the intended bus, that the event actually matches, and that its target configuration points to the expected resource. Then inspect delivery permissions and the target's acceptance behavior.
Official fact: EventBridge uses target-specific permission arrangements, including resource-based policies for supported services. See resource-based policies. Avoid solving every permission problem by adding a broad role; identify which principal, resource, and action are required for that target.
In the receipt exercise, suppose a rule targets a queue whose resource policy no longer allows that rule to send. Rewriting the event pattern would not fix the delivery boundary. A useful investigation links the matching event, target ARN, delivery failure, and effective policy.
Keep target acceptance separate from receipt completion. A queue accepting a message does not prove its consumer sent an email. A function invocation being accepted does not mean its business logic succeeded. The exact acknowledgment boundary depends on the target integration, so state it explicitly in your answer.
Which delivery failures are retried?
Official fact: For retriable target-delivery errors, EventBridge uses the configured retry policy. AWS documents a default of up to 24 hours and up to 185 attempts with exponential backoff and jitter. These are limits, not a promise of exactly 185 attempts. See retry policy.
A shorter maximum age can be appropriate when old events no longer represent useful work. For receipts, delayed processing may remain useful; for a time-sensitive offer, the business may require expiry. Define what the consumer should do with an old event independently of how long EventBridge tries to deliver it.
Official fact: Some failures, such as missing target permissions or a nonexistent target, can go directly to a configured target DLQ without retries. See EventBridge DLQs. Waiting for backoff does not repair a missing permission.
An interview answer should distinguish transient delivery failure, permanent configuration failure, and application failure after acceptance. Those categories determine whether to wait, repair configuration, replay, or reconcile business state.
Why is an empty DLQ weak evidence of success?
Official fact: EventBridge target DLQs use standard SQS queues and need appropriate permissions. AWS exposes metrics for events sent to the DLQ and failures to send there. The DLQ message includes diagnostic attributes such as rule, target, error, and retry information. See DLQ configuration and metadata.
An event that never matched the rule is not a failed delivery to that rule's target. An event successfully accepted by the target but later mishandled by application code is another different case. Neither should be diagnosed solely by inspecting the EventBridge target DLQ.
Use this original boundary ledger:
| Boundary | Evidence to preserve | What an empty target DLQ cannot establish |
|---|---|---|
| Producer submission | Bus identity and per-entry result | That the intended event reached the right bus |
| Rule matching | Pattern version and sample match result | That the rule selected this event |
| Target delivery | Target ARN, invocation outcome, delivery metrics | That the DLQ itself was writable |
| Business processing | Stable operation ID and durable completion state | That a receipt was sent exactly as intended |
During a controlled failure test, deliberately make a test target unavailable in a safe environment and verify the complete failure path. Confirm the DLQ receives the expected diagnostic record and that the alert reaches its owner. Configuration that has never been exercised is weaker evidence than a successful recovery drill.
How is an archive different from a dead-letter queue?
Official fact: Archives retain selected events from a source bus for later replay. Archive capture can lag ingestion, and archive counts are not an instantaneous proof of every recent event. See archiving and replaying.
A DLQ records failed delivery for recovery. An archive preserves a selected historical event stream, including events that may already have been processed successfully. Their selection criteria and operational purposes differ.
In the original scenario, a pattern bug excluded retail payments for twenty minutes. A target DLQ would not automatically contain those unmatched events. An archive might support recovery if its own filter and retention captured the relevant events. Verify that coverage instead of assuming “we have an archive” means every event is recoverable.
Also distinguish replay from rollback. Replaying old events through current business logic may produce different outputs than the original code would have produced. A recovery plan needs the schema interpretation, code behavior, and desired business outcome, not only a time range.
How would you replay without sending duplicate receipts?
Official fact: Replays return archived events to their source bus and can be limited to specified rules and a time interval. See creating replays. Inspect the rules and targets that will receive the replay under the current configuration.
Official fact: Replayed events include replay-name, and replay does not guarantee original arrival order. See archive replay considerations. Do not use archive replay as a substitute for a strictly ordered business log.
The original receipt recovery plan starts by finding affected application event IDs and checking which receipts already completed. Preserve stable operation IDs through replay. The consumer should recognize an already completed receipt and deliberately skip or reconcile it according to the business contract.
Select the narrowest justified time range and intended rules. Test representative old schemas. Estimate downstream load, set a stop condition, and monitor successful business completions separately from replay progress. A completed replay operation does not prove all targets finished processing.
Avoid recursive event loops. If receipt processing publishes another event, ensure the rule does not select that output indefinitely. Name the source and event type for each stage, and test the negative case where an emitted completion event returns to the bus.
Before broad recovery, run a small approved sample and reconcile outcomes. If historical processing must rebuild a read model while suppressing customer-facing notifications, implement and verify that explicit behavior. Simply adding a replay marker is not enough unless the consumer uses it correctly.
Practice the complete delivery argument
The EventBridge follow-ups are original, not claims about the source interviews.
| Interview question | EventBridge follow-up |
|---|---|
| Build Event Notification Engine | Test the receipt pattern with case, type, and nesting changes. |
| Design at-least-once notification delivery | Separate target acceptance from notification completion. |
| Unify Notification Services Without Duplicate Delivery | Preserve business identity through retries and replay. |
| Design async job orchestration and notification service | Assign recovery ownership to each boundary. |
| Design a Reliable Notification System | Explain archive coverage, DLQ evidence, and replay stop conditions. |
Continue with Build Event Notification Engine. Diagnose the missing receipt first as a pattern mismatch, then as target permission failure, then as a consumer bug. Your evidence and recovery plan should change each time.