1. Learning Outcomes#
इस chapter के बाद आप:
- समझ पाएँगे कि EventBridge में event successfully publish होना और subscriber target तक successfully deliver होना दो अलग बातें हैं।
- subscriber target delivery failure का अर्थ समझ पाएँगे।
RetryPolicyका purpose समझ पाएँगे।MaxRetryAttemptsऔरMaxEventAgeInSecondsको सही mental model के साथ समझ पाएँगे।- समझ पाएँगे कि दोनों retry limits में से कोई भी limit पहले पूरी होते ही retrying क्यों रुक सकती है।
- application की latency requirement और expected target outage के अनुसार retry strategy चुन पाएँगे।
- Amazon SQS queue को failure destination के रूप में
OnFailureConfigurationके साथ use करने का purpose समझ पाएँगे। - जान पाएँगे कि retry exhaustion के बाद DLQ configured न हो तो event के साथ क्या होता है।
- EventBridge failure record से error code, retry information, target ARN और failed event identification जैसी details inspect करना समझ पाएँगे।
- delivery role की target invocation और
sqs:SendMessagepermissions का महत्व समझ पाएँगे। - Access Denied, missing resource, throttling, transformation failure और target timeout जैसे common failures diagnose कर पाएँगे।
EventsDropped,OnFailureDestinationDeliveredऔरOnFailureDestinationFailedmetrics का operational meaning समझ पाएँगे।- failed events reprocess करने से पहले root cause fix करने की सही strategy समझ पाएँगे।
- retained event को event bus से replay करके recovery करने का basic flow समझ पाएँगे।
- समझ पाएँगे कि replay केवल तब possible है जब original event अभी event bus retention period के अंदर available हो।
- modern custom event bus subscribers के लिए पुराने या classic retry assumptions पर निर्भर न रहकर explicit configuration करना सीखेंगे।
2. Main Concepts and English Definitions#
इस chapter में कुछ terms बार-बार आएँगी। पहले उनका professional English meaning और फिर आसान अर्थ समझ लेते हैं।
| Concept | English Definition | आसान अर्थ |
|---|---|---|
| Target Delivery Failure | A target delivery failure occurs when EventBridge has accepted an event but cannot successfully deliver it to the configured subscriber target. | Event bus ने event ले लिया, लेकिन downstream target तक पहुँचाना सफल नहीं हुआ। |
| Retry Policy | A retry policy defines how EventBridge should continue attempting delivery after a target delivery failure. | delivery fail होने के बाद EventBridge कितनी देर और कितनी बार कोशिश करे, यह policy तय करती है। |
| MaxRetryAttempts | The maximum number of retry attempts allowed for a failed target delivery. | failure के बाद attempts की upper limit। |
| MaxEventAgeInSeconds | The maximum age an event may reach while EventBridge is still allowed to retry its delivery. | event कितना पुराना होने तक retry किया जा सकता है, उसकी time limit। |
| Dead-Letter Queue | A dead-letter queue is a failure destination used to retain information about events that could not be successfully delivered after normal delivery handling. | delivery पूरी तरह fail होने पर investigation और recovery के लिए failure information रखने वाली SQS queue। |
| OnFailureConfiguration | Configuration that tells EventBridge where failure information should be sent when delivery can no longer continue. | retries खत्म होने पर failure record कहाँ भेजना है, यह configuration बताती है। |
| Delivery Role | An IAM role whose permissions allow EventBridge to perform the actions required to deliver an event to a subscriber target and related failure destination. | EventBridge को target और जरूरत होने पर DLQ तक action करने की permission देने वाला IAM role। |
| Event Replay | Reprocessing retained events by sending them again from the event bus after the underlying failure has been corrected. | पुराने retained events को root cause fix होने के बाद दोबारा process करवाना। |
| Event Retention | The period during which an event remains available on the event bus for later operations such as replay. | event bus original event को कितनी देर available रखता है। |
3. एक Important Distinction: Publish Success और Delivery Success#
मान लीजिए आपका Java Order Service एक event publish करता है:
OrderPlaced
EventBridge उस event को successfully accept कर लेता है।
Producer को लगता है:
"Event publish हो गया।"
यह बात सही है।
लेकिन इसका यह मतलब नहीं है कि subscriber target ने भी event successfully process कर लिया।
यहाँ दो अलग stages हैं:
- producer से EventBridge तक event पहुँचना
- EventBridge से subscriber target तक event पहुँचना
इन दोनों को एक ही success मत समझिए।
Rendering diagram…
Diagram could not be rendered.
इस diagram में producer को EventBridge से acceptance मिल चुकी है।
फिर भी target delivery fail हो सकती है।
Event publishing success केवल यह confirm करता है कि EventBridge ने event accept किया। यह subscriber target की successful delivery की guarantee नहीं है।
यह distinction production systems में बहुत important है।
अगर Java application केवल publish success देखकर मान ले कि पूरा business workflow complete हो गया, तो downstream failures छिप सकते हैं।
उदाहरण:
- Order Service ने
OrderPlacedpublish किया। - EventBridge ने event accept किया।
- Inventory subscriber unavailable था।
- target delivery fail हो गई।
- Order Service के publish operation को फिर भी success मिल चुका था।
इसलिए event-driven architecture में producer success और downstream processing success अलग concerns हैं।
4. Subscriber Target Delivery Failure क्या है?#
Subscriber target वह downstream destination है जहाँ EventBridge event deliver करने की कोशिश करता है।
यह target किसी application, AWS service या configured integration का endpoint हो सकता है।
जब EventBridge target तक event successfully deliver नहीं कर पाता, तो इसे target delivery failure समझ सकते हैं।
Delivery failure किन कारणों से हो सकती है?#
Common कारण:
- permission missing
- target resource missing
- target throttling
- transformation failure
- target timeout
- temporary target outage
इनमें से कुछ temporary होते हैं।
कुछ permanent configuration problems होते हैं।
यही reason है कि retry system useful है।
Temporary failure में थोड़ी देर बाद वही delivery successful हो सकती है।
लेकिन permanent failure में 100 बार retry करने से भी problem solve नहीं होगी।
उदाहरण:
अगर delivery role के पास target invoke करने की permission ही नहीं है, तो केवल retry करते रहने से permission अपने आप नहीं आएगी।
इसलिए retry और diagnosis दोनों जरूरी हैं।
5. RetryPolicy क्यों चाहिए?#
मान लीजिए target service कुछ मिनट के लिए unavailable है।
अगर EventBridge पहली failure के बाद तुरंत event permanently छोड़ दे, तो temporary outage के कारण business event खो सकता है।
इसलिए EventBridge retry कर सकता है।
RetryPolicy यह नियंत्रित करती है कि failed delivery को कितनी attempts और कितने समय तक retry करने की अनुमति है।
Mental Model#
Retry policy को दो safety boundaries की तरह सोचिए:
- attempt boundary
- time boundary
EventBridge unlimited retry नहीं करता।
Retrying का एक operational end होना चाहिए।
यही काम MaxRetryAttempts और MaxEventAgeInSeconds करते हैं।
6. MaxRetryAttempts#
MaxRetryAttempts बताता है कि failed target delivery के लिए कितने retry attempts allowed हैं।
Simple example:
मान लीजिए आपने relatively small retry count चुना।
Delivery लगातार fail होती रहती है।
हर unsuccessful retry के साथ allowed retry budget consume होता जाता है।
जब configured retry-attempt limit पहुँच जाती है, retrying continue नहीं करनी चाहिए।
अधिक retry attempts हमेशा बेहतर नहीं होते। Permanent configuration failure में अधिक attempts केवल repeated failures create कर सकते हैं।
7. MaxEventAgeInSeconds#
अब दूसरा control समझिए।
MaxEventAgeInSeconds event की retry lifetime को time के हिसाब से limit करता है।
यह पूछता है:
"यह event कितनी देर पुराना होने तक अभी भी useful है?"
यह business requirement पर depend करता है।
उदाहरण के लिए:
Real-time authorization जैसी operation में बहुत पुराना event शायद useful न हो।
लेकिन asynchronous reporting event के लिए larger recovery window acceptable हो सकती है।
इसलिए केवल retry count देखना पर्याप्त नहीं है।
Event की useful age भी important है।
8. Retry Attempts और Event Age साथ कैसे काम करते हैं?#
यह chapter का सबसे important retry concept है।
EventBridge के पास दो boundaries हैं:
- maximum retry attempts
- maximum event age
Retry process उस boundary तक नहीं चलता जिसे आप mentally "main" मानते हैं।
इन दोनों में से जो limit पहले reach होती है, वही retry process रोक सकती है।
Rendering diagram…
Diagram could not be rendered.
मान लीजिए attempt limit अभी बाकी है।
लेकिन event age limit पूरी हो गई।
तो केवल इसलिए retry continue नहीं होनी चाहिए कि attempts अभी remaining हैं।
दूसरी तरफ event अभी बहुत पुराना नहीं हुआ है, लेकिन retry-attempt limit पूरी हो गई।
तब भी retrying रुक सकती है।
MaxRetryAttempts और MaxEventAgeInSeconds को independent safety limits समझिए। दोनों में से कोई भी limit retry lifecycle समाप्त कर सकती है।
9. Retry Duration कैसे चुनें?#
Retry configuration blindly copy नहीं करनी चाहिए।
आपको दो questions पूछने चाहिए:
- target कितनी देर unavailable रह सकता है?
- business के लिए event कितनी देर तक useful है?
Scenario 1: Short-Lived API Workflow#
मान लीजिए event का business value केवल कुछ मिनट है।
20 या 30 मिनट बाद उसका action meaningful नहीं रहेगा।
ऐसे case में बहुत लंबा retry window रखने का फायदा कम हो सकता है।
Scenario 2: Temporary Downstream Outage#
मान लीजिए downstream service deployment के दौरान कुछ समय unavailable रह सकती है।
अगर business event बाद में process किया जा सकता है, तो retry window उस realistic outage को cover करने लायक होनी चाहिए।
Scenario 3: Permanent Permission Failure#
अगर target invoke permission missing है, तो outage duration के आधार पर retry बढ़ाना root cause नहीं solve करेगा।
यहाँ IAM fix जरूरी है।
इसलिए retry policy availability problem handle करती है।
Configuration bug को magically repair नहीं करती।
10. Application Latency Requirement भी देखिए#
Retry policy का decision केवल infrastructure decision नहीं है।
यह business latency decision भी है।
मान लीजिए customer payment के बाद expected downstream update 2 मिनट में होना चाहिए।
अगर retry configuration event को बहुत लंबे समय तक pending रखती है, तो technically delivery eventually successful हो सकती है लेकिन business SLA fail हो सकता है।
इसलिए सोचें:
Expected target outage बनाम Maximum acceptable business delay
दोनों को balance करना है।
Retry window को केवल "जितना बड़ा उतना safe" मानना गलत है। बहुत पुराना event application के लिए obsolete भी हो सकता है।
11. Retry Exhaustion के बाद क्या होता है?#
मान लीजिए:
- delivery fail हुई
- retries हुए
- retry limits पूरी हो गईं
अब EventBridge को decide करना है कि failure information कहाँ जाए।
यहाँ OnFailureConfiguration महत्वपूर्ण बनती है।
अगर Amazon SQS failure destination configured है, तो failed delivery information उस queue में भेजी जा सकती है।
अगर failure destination configured नहीं है, तो retry lifecycle खत्म होने के बाद event dropped हो सकता है।
यही reason है कि production systems में केवल retries configure करना पर्याप्त नहीं है।
Failure path भी design करना चाहिए।
12. Amazon SQS Dead-Letter Queue का Purpose#
SQS dead-letter queue को यहाँ investigation और recovery mechanism के रूप में सोचिए।
Normal path:
EventBridge → Subscriber Target
Failure path:
EventBridge → SQS DLQ
DLQ का purpose यह है कि exhausted failure invisible न हो जाए।
Operations team failure record inspect कर सके।
Application team root cause diagnose कर सके।
Recovery process decide किया जा सके।
Retry temporary failure से recover करने की कोशिश है। DLQ exhausted failure को observable और diagnosable बनाती है।
13. OnFailureConfiguration#
OnFailureConfiguration बताती है कि normal delivery और retries के बाद unsuccessful failure information कहाँ भेजनी है।
इस chapter के context में destination एक Amazon SQS dead-letter queue है।
Conceptual flow:
Rendering diagram…
Diagram could not be rendered.
इस flow में DLQ normal subscriber path नहीं है।
वह failure path है।
इसलिए DLQ को monitoring और incident response के साथ जोड़ना चाहिए।
14. DLQ को Original Event Store समझने की गलती#
एक important operational distinction समझिए।
DLQ failure record को केवल "original event की ready-to-republish copy" मानकर recovery design करना safe mental model नहीं है।
Failure record का सबसे important purpose delivery failure context देना है।
आपको failure investigation के लिए information मिल सकती है जैसे:
- error code
- retry count
- failed event identifier
- target ARN
- delivery failure details
इसलिए operationally DLQ को failure evidence की तरह treat करें।
Original business event की reliable replay strategy event-bus retention पर आधारित हो सकती है।
DLQ record और retained original event की responsibility एक जैसी नहीं है। DLQ failure diagnose करने में मदद करती है; retained event recovery replay का source बन सकता है।
15. Failure Record में क्या Inspect करना चाहिए?#
किसी failure record को देखकर केवल payload मत देखिए।
सबसे पहले failure context समझिए।
Useful details में शामिल हो सकते हैं:
| Detail | क्या बताती है |
|---|---|
| Error Code | target delivery क्यों fail हुई |
| Retry Count | delivery को कितनी retry attempts मिलीं |
| Target ARN | किस target पर delivery fail हुई |
| Failed Event ID | कौन-सा event failure से संबंधित है |
| Failure Context | permission, availability या target-side problem की दिशा |
मान लीजिए error Access Denied है।
यह target application का business bug होने से ज्यादा IAM problem की ओर संकेत कर सकता है।
अगर target ARN unexpected है, तो configuration गलत resource की ओर point कर रही हो सकती है।
अगर retries बहुत हुईं और हर बार timeout आया, तो target availability या latency investigate करनी चाहिए।
16. Delivery Role क्यों Important है?#
EventBridge किसी subscriber target को invoke करते समय required AWS permission के बिना action नहीं कर सकता।
Delivery role वह IAM identity है जिसके permissions delivery operation के लिए उपयोग हो सकते हैं।
इस role को कम से कम वह permission चाहिए जो configured target invoke करने के लिए required है।
उदाहरण के लिए target type के अनुसार action अलग हो सकती है।
Important principle:
Target-specific permission must exist.
अगर permission नहीं है:
Event exists.
Subscriber configuration exists.
Target resource exists.
फिर भी delivery Access Denied के कारण fail हो सकती है।
17. DLQ के लिए sqs:SendMessage Permission#
अगर failure destination Amazon SQS queue है, तो EventBridge delivery flow को उस queue में failure information भेजने की permission भी चाहिए।
इसलिए relevant delivery permissions में sqs:SendMessage महत्वपूर्ण हो सकती है।
Mental model:
- target permission → normal delivery के लिए
sqs:SendMessage→ failure destination के लिए
अब एक subtle failure देखिए।
Target invocation fail हुई।
Retries exhausted हुईं।
EventBridge failure information DLQ में भेजना चाहता है।
लेकिन DLQ send permission भी missing है।
अब primary delivery भी fail हुई और failure recording path भी fail हो गया।
यही कारण है कि failure destination permission production readiness का हिस्सा है।
DLQ configure करना पर्याप्त नहीं है। EventBridge को उस failure destination तक successfully send करने की permission भी चाहिए।
18. Common Delivery Failures#
अब common failure categories को systematically समझते हैं।
1. Access Denied#
EventBridge target invoke करने की कोशिश करता है।
लेकिन required permission उपलब्ध नहीं है।
Typical investigation:
- delivery role check करें
- target-specific permission check करें
- correct resource ARN check करें
- failure destination permission भी verify करें
Retry alone permanent permission error को solve नहीं करती।
2. Missing Resource#
Configured target delete हो गया हो सकता है।
ARN गलत हो सकती है।
Deployment ने resource replace किया हो सकता है।
Configuration stale हो सकती है।
EventBridge ऐसे resource तक delivery नहीं कर सकता जो exist ही नहीं करता या गलत reference से configured है।
3. Throttling#
Target service request rate accept नहीं कर पा रही।
यह temporary capacity problem हो सकती है।
इस situation में retries useful हो सकती हैं।
लेकिन repeated throttling capacity planning या quota issue की ओर संकेत करती है।
4. Transformation Failure#
Event target तक जाने से पहले transformation या mapping configured हो सकती है।
अगर expected structure और actual event structure mismatch हो जाए, delivery path fail हो सकती है।
इसलिए transformation failure में केवल target health check करना पर्याप्त नहीं है।
Transformation configuration भी inspect करें।
5. Target Timeout#
Target expected समय में response या processing acknowledgment नहीं दे पाता।
Possible कारण:
- target overloaded है
- downstream dependency slow है
- network/integration latency अधिक है
- application processing unnecessarily synchronous है
Retries temporary timeout से recover कर सकती हैं।
लेकिन लगातार timeout root performance problem की ओर संकेत करता है।
19. Failure Type और First Investigation#
| Failure | पहले क्या जाँचें |
|---|---|
| Access Denied | IAM delivery permissions |
| Missing Resource | target ARN और resource existence |
| Throttling | target capacity, quota और request load |
| Transformation Failure | transformation/mapping configuration |
| Target Timeout | target latency और downstream dependencies |
| DLQ Send Failure | SQS destination और sqs:SendMessage permission |
यह table incident response में useful है क्योंकि हर failure को "service down है" मानना गलत होगा।
20. Monitoring: Retry System को Observe कैसे करें?#
Failure handling तभी useful है जब आप उसे monitor कर सकें।
इस chapter में तीन important metrics पर focus करें:
EventsDroppedOnFailureDestinationDeliveredOnFailureDestinationFailed
21. EventsDropped#
EventsDropped बढ़ना serious signal है।
इसका basic meaning है कि delivery lifecycle ऐसी स्थिति में पहुँची जहाँ event successfully target तक deliver नहीं हुआ और अब उसे normal retry path में continue नहीं किया जा रहा।
अगर DLQ configured नहीं है, dropped events operationally अधिक dangerous हो सकते हैं क्योंकि dedicated failure destination नहीं है।
इस metric को silently बढ़ने देना production risk है।
22. OnFailureDestinationDelivered#
यह metric बताने में मदद करती है कि exhausted failure को configured failure destination तक successfully पहुँचाया गया।
मान लीजिए subscriber target fail हुआ।
Retries exhausted हुईं।
SQS DLQ configured थी।
Failure record DLQ तक पहुँच गया।
यह primary business delivery success नहीं है।
यह केवल failure-handling path success है।
OnFailureDestinationDelivered बढ़ना अच्छी business delivery का signal नहीं है। इसका मतलब failure safely captured हुआ है।
23. OnFailureDestinationFailed#
यह अधिक dangerous signal है।
इसका मतलब failure destination तक failure record भेजने का प्रयास भी unsuccessful रहा।
Possible कारण:
- SQS permission problem
- wrong queue configuration
- missing destination
- failure-path configuration issue
अगर यह metric बढ़ती है, तो आपके पास "failure of the failure handler" जैसी situation है।
Normal delivery fail हुई।
Failure destination भी fail हुई।
इसलिए इसे high-priority operational condition समझना चाहिए।
24. Metrics को साथ देखकर Diagnosis करें#
| Observation | Possible Interpretation |
|---|---|
EventsDropped बढ़ रही है |
deliveries retry lifecycle से बाहर जा रही हैं |
OnFailureDestinationDelivered बढ़ रही है |
exhausted failures DLQ तक पहुँच रही हैं |
OnFailureDestinationFailed बढ़ रही है |
failure destination path भी broken हो सकता है |
| target errors + repeated retries | underlying target problem अभी unresolved है |
Single metric से पूरी story नहीं मिलती।
Metrics को failure records और target logs के साथ correlate करना चाहिए।
25. Root Cause Fix किए बिना Redrive क्यों नहीं करना चाहिए?#
मान लीजिए Access Denied के कारण 500 events fail हुए।
आपने तुरंत replay शुरू कर दिया।
लेकिन IAM permission अभी भी missing है।
क्या होगा?
वही 500 events फिर fail होंगे।
फिर retries होंगी।
फिर DLQ records बढ़ेंगे।
System पर unnecessary load आएगा।
Investigation और noisy हो जाएगी।
सही order यह है:
- failure detect करें
- failure details inspect करें
- root cause identify करें
- root cause fix करें
- fresh event से delivery verify करें
- उसके बाद retained failed events replay करें
Replay recovery step है, diagnosis step नहीं। पहले कारण ठीक करें, फिर पुराने events reprocess करें।
26. Practical Incident Example#
मान लीजिए Java backend का OrderPlaced event Inventory subscriber तक नहीं पहुँच रहा।
आप देखते हैं:
- publisher को successful publish response मिल रहा है
- subscriber processing नहीं हो रही
- retries हो रही हैं
- failure destination records आ रहे हैं
Investigation में Error Code permission-related दिखाई देता है।
अब सही action क्या है?
Retries बढ़ाना?
नहीं।
पहले delivery role की target invocation permission fix करनी है।
फिर एक नया test event publish करें।
अगर target delivery सफल होती है, तो root cause fixed होने का confidence बढ़ता है।
उसके बाद retained events replay किए जा सकते हैं।
27. Event Replay क्या है?#
Replay का अर्थ है retained event को फिर से delivery flow में भेजना ताकि target उसे दोबारा process कर सके।
यह especially useful है जब:
- original delivery failed थी
- root cause fix हो चुका है
- original event अभी event bus retention period के अंदर है
Recovery flow:
Rendering diagram…
Diagram could not be rendered.
इस diagram का सबसे important decision है:
Original event still retained?
Replay capability को unlimited historical storage मत समझिए।
28. Retention Period क्यों Critical है?#
अगर original event event bus retention period से बाहर जा चुका है, तो event bus से replay करने के लिए वह event उपलब्ध नहीं रहेगा।
इसलिए recovery readiness में केवल DLQ monitoring नहीं, retention strategy भी important है।
मान लीजिए:
- failure Monday को हुई
- team ने Friday को issue notice किया
- retention window इससे छोटी थी
तो root cause fix होने के बाद भी original event bus replay के लिए उपलब्ध नहीं हो सकता।
इसलिए operational detection delay और retention period एक-दूसरे से जुड़े हुए हैं।
"DLQ है, इसलिए हम कभी भी बाद में replay कर लेंगे" मानना unsafe है। Replay का source और उसकी retention window अलग concern है।
29. DLQ और Event Bus Retention का Relationship#
इन दोनों को अलग responsibilities के रूप में समझिए।
DLQ#
मुख्य purpose:
- exhausted failure visible करना
- failure metadata preserve करना
- diagnosis में मदद करना
Event Bus Retention#
मुख्य purpose:
- original retained events को limited period तक available रखना
- root cause fix होने के बाद replay enable करना
इसलिए robust recovery design में दोनों complementary हो सकते हैं।
एक diagnosis में मदद करता है।
दूसरा reprocessing opportunity देता है।
30. Java Backend Developer के लिए Recovery Mental Model#
Java developer के perspective से flow इस प्रकार सोचें:
Producer:
Order Service
Event:
OrderPlaced
Subscriber:
Inventory Service
Failure:
Inventory target temporarily unavailable
Recovery:
- EventBridge retries
- retries fail होने पर DLQ failure record मिलता है
- monitoring alert देती है
- engineer root cause fix करता है
- new event से target validate करता है
- retained
OrderPlacedevents replay करता है
यह design producer को tightly coupled retry loop लिखने से बचाता है।
लेकिन इसका मतलब यह नहीं कि developer failure handling ignore कर सकता है।
Infrastructure-level retry और application-level correctness दोनों जरूरी हैं।
Idempotency Reminder#
Retry या replay के कारण application को same business event फिर receive हो सकता है।
इसलिए subscriber processing ideally duplicate-safe होनी चाहिए।
यहाँ deep idempotency design नहीं करेंगे, लेकिन production Java backend में यह important safety principle है।
31. Retry Policy Selection: एक Decision Framework#
Configuration करते समय यह sequence उपयोग करें।
Step 1: Business Event की Lifetime पूछें#
क्या event:
- seconds में useful है?
- minutes में useful है?
- लंबे asynchronous workflow का हिस्सा है?
Step 2: Expected Outage समझें#
Target की temporary unavailability realistically कितनी देर हो सकती है?
Step 3: Retry Attempts Limit करें#
Repeated failures को unlimited attempts में बदलना सही नहीं है।
Step 4: Event Age Limit करें#
Business value से ज्यादा पुराना event blindly process नहीं करना चाहिए।
Step 5: Failure Destination Configure करें#
Retry exhaustion के बाद failure invisible नहीं होना चाहिए।
Step 6: IAM Validate करें#
Target और DLQ दोनों paths की permissions verify करें।
Step 7: Monitoring Configure करें#
कम से कम dropped events और failure-destination success/failure observe करें।
Step 8: Recovery Runbook बनाएँ#
Root cause fix → test → replay → verify.
यह systematic design production incident के समय confusion कम करता है।
32. Classic Retry Defaults पर Depend क्यों नहीं करना चाहिए?#
AWS services evolve होती हैं।
Older EventBridge delivery patterns के retry defaults और modern custom event bus subscriber behavior को blindly interchangeable मानना सही approach नहीं है।
Modern subscriber configuration में retry behavior को explicit design decision मानें।
यानी:
- "default शायद पर्याप्त होगा" पर depend न करें
- desired retry attempts explicitly decide करें
- desired event age explicitly decide करें
- failure destination explicitly plan करें
- monitoring explicitly plan करें
Production reliability assumptions से नहीं, explicit configuration और observable behavior से बनती है।
33. एक Complete Delivery Failure Story#
अब पूरा lifecycle एक साथ देखते हैं।
Stage 1: Producer Publishes Event#
Java Order Service EventBridge पर OrderPlaced publish करता है।
EventBridge event accept कर लेता है।
Producer-side publish successful है।
Stage 2: EventBridge Delivers to Subscriber#
EventBridge Inventory subscriber target को event deliver करने की कोशिश करता है।
Target timeout देता है।
Delivery failed।
Stage 3: RetryPolicy Applies#
EventBridge retry policy के अनुसार दो boundaries track करता है:
- retry attempts
- event age
Stage 4: Retry Succeeds या Limits Exhaust होती हैं#
अगर target recover कर गया, delivery सफल हो सकती है।
अगर failure जारी रही और कोई retry boundary reach हो गई, retries बंद हो जाती हैं।
Stage 5: Failure Destination#
SQS DLQ configured है तो failure information वहाँ भेजी जाती है।
अगर failure destination available नहीं है, failure-path monitoring महत्वपूर्ण हो जाती है।
Stage 6: Operations Detect Problem#
Metrics और DLQ record से engineer पता लगाता है कि target repeatedly timeout हो रहा था।
Stage 7: Root Cause Fix#
Inventory service की performance problem fix की जाती है।
Stage 8: New Delivery Verify#
Fresh event भेजकर confirm किया जाता है कि target अब healthy है।
Stage 9: Replay#
अगर original events अभी event bus retention period के अंदर available हैं, retained events replay किए जाते हैं।
Stage 10: Verify Recovery#
Subscriber processing verify की जाती है।
Metrics normalize होनी चाहिए।
Failure destination में नए unexpected records नहीं आने चाहिए।
यही complete reliability loop है।
34. Common Mistakes#
Mistake 1: Publish Success = End-to-End Success#
यह सबसे basic misconception है।
Producer acknowledgment downstream subscriber processing की guarantee नहीं है।
Mistake 2: Retry ही Complete Recovery Strategy है#
Retry केवल retryable failures के लिए useful है।
Permanent IAM/configuration problems के लिए diagnosis जरूरी है।
Mistake 3: केवल Retry Count Configure करना#
Event age business relevance को control करती है।
दोनों limits समझनी चाहिए।
Mistake 4: DLQ Configure करके Permission भूल जाना#
Failure destination configured है लेकिन EventBridge वहाँ send नहीं कर सकता।
Result: failure-handling path भी fail।
Mistake 5: DLQ Record को Blindly Original Event मान लेना#
Failure record को investigation context की तरह treat करें।
Reliable recovery strategy retained original event और replay availability को ध्यान में रखे।
Mistake 6: Root Cause Fix किए बिना Replay#
यह वही failures फिर create कर सकता है।
Mistake 7: Retention Window Ignore करना#
बहुत देर से recovery शुरू की तो original event replay के लिए available न हो।
Mistake 8: Classic Defaults Assume करना#
Modern subscriber reliability को explicit configuration से control करें।
35. Operational Checklist#
Production subscriber configure करते समय यह checklist useful है:
- subscriber target correct है
- target ARN correct है
- delivery role target invoke कर सकती है
- retry behavior explicitly configured है
MaxRetryAttemptsapplication requirement के अनुसार chosen हैMaxEventAgeInSecondsbusiness latency के अनुसार chosen है- SQS failure destination configured है
- delivery flow को
sqs:SendMessagepermission उपलब्ध है EventsDroppedmonitored हैOnFailureDestinationDeliveredmonitored हैOnFailureDestinationFailedmonitored है- team के पास root-cause-first recovery runbook है
- event retention recovery requirement को support करती है
- subscriber retry/replay duplicates safely handle कर सकता है
36. Interview Preparation#
An EventBridge event was published successfully. Does that guarantee the subscriber received it successfully?Show Answer
No.
Successful publishing means EventBridge accepted the event.
Subscriber delivery is a separate stage.
Target permissions, throttling, missing resources, transformation failures, timeouts, or outages can still cause target delivery failure.
A production design should therefore use retry configuration, failure handling, monitoring, and recovery mechanisms.
How do MaxRetryAttempts and MaxEventAgeInSeconds work together?Show Answer
They provide two independent boundaries for retrying a failed target delivery.
MaxRetryAttempts limits retry count.
MaxEventAgeInSeconds limits how old the event may become while retries continue.
Retrying stops when the applicable retry lifecycle reaches either configured boundary first.
Why configure an SQS dead-letter queue for EventBridge subscriber failures?Show Answer
It provides an observable failure destination after normal delivery and retry handling can no longer complete successfully.
The failure record helps investigate details such as the target, error, retries, and failed event identity.
The underlying root cause should be fixed before events are reprocessed.
Why should events not be replayed immediately after seeing failures?Show Answer
Because the root cause may still exist.
Replaying before fixing permissions, target availability, throttling, transformation, or timeout problems can reproduce the same failures.
The safer sequence is diagnose, fix, validate a fresh delivery, and then replay retained events.
Strong answer केवल "EventBridge retries failed events" तक सीमित नहीं होना चाहिए। Retry limits, DLQ, IAM, monitoring, root-cause correction और retained-event replay का relationship explain करें।
37. What You Should Remember#
- EventBridge event acceptance और subscriber target delivery अलग stages हैं।
- Publish success downstream success की guarantee नहीं है।
RetryPolicyfailed target delivery के retry lifecycle को control करती है।MaxRetryAttemptsattempts की limit है।MaxEventAgeInSecondsretryable event lifetime की limit है।- दोनों में से कोई limit पहले reach हो तो retrying रुक सकती है।
- retry duration business latency और expected outage दोनों देखकर choose करें।
- exhausted failures के लिए SQS DLQ useful failure destination है।
- failure record का मुख्य value diagnosis context है।
- target delivery और DLQ दोनों के IAM permissions सही होने चाहिए।
EventsDroppedignored नहीं होना चाहिए।OnFailureDestinationDeliveredfailure capture success दिखाता है, business processing success नहीं।OnFailureDestinationFailedfailure path की problem दिखा सकता है।- replay से पहले root cause fix करें।
- replay केवल retained original event available होने तक possible है।
- modern subscriber behavior के लिए explicit retry configuration पर भरोसा करें, पुराने defaults पर नहीं।
Reliable EventBridge subscriber design का पूरा flow है: publish को delivery से अलग समझना, sensible retry limits set करना, exhausted failures को SQS DLQ में capture करना, IAM और metrics से failures diagnose करना, root cause fix करना, और retention उपलब्ध होने पर retained events replay करना।