SQS संदेश फ़िल्टरिंग और SNS + SQS एकीकरण

Filtering के बिना fan-out architecture में प्रत्येक SQS subscriber को SNS का हर संदेश मिलता है। यदि आपका topic 10 अलग-अलग product categories के order events प्रकाशित करता है, लेकिन कोई subscriber केवल electronics orders संसाधित करता है, तो भी उसे food और clothing messages प्राप्त करके छोड़ने पड़ते हैं। इससे compute व्यर्थ होता है, लागत बढ़ती है और consumers पर अनावश्यक भार पड़ता है। SNS subscription filter policies इस समस्या को हल करती हैं, क्योंकि SNS स्वयं संदेशों को केवल उपयुक्त subscribers तक route करता है।

filter policy SQS या Lambda subscription पर लागू की जाने वाली JSON object होती है। डिलीवरी से पहले SNS प्रत्येक संदेश की message attributes की तुलना policy से करता है। यदि message attributes filter policy से मेल खाते हैं, तो संदेश deliver किया जाता है; अन्यथा SNS उस subscriber को चुपचाप छोड़ देता है। Filter policies string matching, numeric ranges, prefix matching और attribute की मौजूदगी या अनुपस्थिति जाँचने के लिए exists operator का समर्थन करती हैं।

डिफ़ॉल्ट रूप से filter policies message attributes (metadata) से मिलान करती हैं। 2023 से SNS MessageBody पर filter policy scope सेट करके payload-based (body) filtering का भी समर्थन करता है। इससे publishers को attributes जोड़ने की आवश्यकता के बिना सीधे message body पर JSON path-आधारित filtering की जा सकती है। Body filtering अधिक लचीली है, लेकिन message body का मान्य JSON होना आवश्यक है। हमेशा जाँच लें कि कौन-सा scope आपके publisher के output format से मेल खाता है।

Filter policies साधारण string equality के अलावा कई matching operators का समर्थन करती हैं:

• Numeric: {"numeric": ["=", 100]}, {"numeric": [">", 50, "<=", 200]}
• Prefix: {"prefix": "order-"} उस prefix से शुरू होने वाली किसी भी string से मेल खाता है
• Anything-but: {"anything-but": ["CANCELLED"]} सूचीबद्ध values को छोड़कर किसी भी value से मेल खाता है
• Exists: {"exists": true} तब मेल खाता है जब attribute मौजूद हो; अनुपस्थित होने पर false

Filtering के काम करने के लिए publisher must include message attributes जब वह SNS पर publish करे। Attributes data type (String, Number, Binary) वाले key-value pairs होते हैं। Publisher को यह जानने की आवश्यकता नहीं होती कि किन subscribers के पास कौन-सी filter policies हैं—वह केवल event का वर्णन करने वाले attributes से संदेश को समृद्ध करता है। SNS routing अपने-आप संभालता है। इससे publishers subscriber-विशिष्ट logic से पूरी तरह अलग रहते हैं।

एक उन्नत fan-out topology में SNS अलग-अलग specificity levels पर SQS queues को route कर सकता है: एक queue auditing के लिए all orders प्राप्त करती है (कोई filter नहीं), दूसरी केवल HIGH_VALUE orders (amount >= 1000) fraud review के लिए प्राप्त करती है और तीसरी केवल ELECTRONICS orders electronics warehouse के लिए प्राप्त करती है। प्रत्येक SQS queue का अपना Lambda consumer होता है। यह पैटर्न प्रत्येक processing tier को स्वतंत्र रूप से scale करता है और मौजूदा consumers या publisher में बदलाव किए बिना नए consumers जोड़ने देता है।

SNS किसी different AWS account में मौजूद SQS queues तक डिलीवरी कर सकता है। SQS queue की resource-based policy में SNS service principal को publishing account के SNS topic ARN से sqs:SendMessage call करने की अनुमति होनी चाहिए। इससे credentials साझा किए बिना centralised event publishing संभव होती है (एक account publish करता है और कई account teams subscribe करती हैं)। Multi-account AWS Organizations setups में cross-account fan-out एक सामान्य पैटर्न है।

जब event volume अचानक बढ़ता है, तो सीधे SNS-to-Lambda invocations Lambda को तुरंत scale करती हैं और इससे downstream databases या APIs पर अत्यधिक भार पड़ सकता है। SNS और Lambda के बीच SQS जोड़ने से एक buffer बनता है: SNS SQS तक डिलीवरी करता है और Lambda नियंत्रित batch size पर SQS को poll करता है। इससे Lambda टिकाऊ दर पर प्रसंस्करण कर पाता है, जबकि SQS traffic spikes को संभालता है। Queue की depth backpressure mechanism के रूप में काम करती है—आप इसकी निगरानी कर सकते हैं और threshold से अधिक बढ़ने पर alert कर सकते हैं, जो consumer lag का संकेत है।

SNS → Lambda (direct): सबसे कम latency, कोई buffering नहीं, Lambda तुरंत scale होता है। यह real-time alerting या urgent notifications के लिए सर्वोत्तम है, जहाँ sub-second latency महत्वपूर्ण होती है। SNS → SQS → Lambda: इसमें DLQ support, नियंत्रित throughput, visibility timeout के साथ retry और queue depth monitoring मिलती है। यह transaction processing, inventory updates और उन सभी scenarios के लिए सर्वोत्तम है जहाँ downstream limits का सम्मान करना आवश्यक हो। परीक्षा के प्रश्नों में durability और rate control का उल्लेख होने पर SQS buffering चुनें।

परिनियोजन से पहले यह जाँचने के लिए कि कोई नमूना संदेश आपकी फ़िल्टर नीति से मेल खाएगा या नहीं, SNS कंसोल के फ़िल्टर नीति संपादक का उपयोग करें। संदेश वितरण का अनुकरण करने और रूटिंग की पुष्टि करने के लिए आप SNS Sandbox का भी उपयोग कर सकते हैं। कोड में, ज्ञात विशेषताओं वाले परीक्षण संदेश प्रकाशित करके और प्रत्येक सदस्यता के लिए CloudWatch मेट्रिक्स की जाँच करके फ़िल्टर नीतियों का सत्यापन करें: NumberOfMessagesFiltered मेट्रिक दिखाता है कि फ़िल्टर द्वारा कितने संदेश रोके गए, जिससे आपको उत्पादन घटनाओं की प्रतीक्षा किए बिना नीतियों को बेहतर बनाने में सहायता मिलती है।

एक पूर्ण SNS + SQS एकीकरण इस प्रकार काम करता है: (1) एप्लिकेशन संदेश विशेषताओं सहित किसी SNS Standard topic पर कोई घटना प्रकाशित करता है; (2) SNS प्रत्येक सदस्यता की फ़िल्टर नीति का मूल्यांकन करता है और केवल मेल खाने वाले संदेश प्रत्येक SQS कतार तक पहुँचाता है; (3) Lambda कॉन्फ़िगर किए गए बैच आकार के साथ प्रत्येक SQS कतार से संदेश प्राप्त करता है और उन्हें संसाधित करता है; (4) विफल संदेश maxReceiveCount के बाद कतार की DLQ तक पहुँचते हैं; (5) DLQ की गहराई पर लगा CloudWatch अलार्म टीम को सचेत करता है। यह पूरी तरह अलग किया गया और लचीला पैटर्न एक आदर्श SAA-C03 आर्किटेक्चर है।

इस पाठ में आपने सीखा: SNS फ़िल्टर नीतियाँ SNS स्तर पर संदेश की विशेषताओं या मुख्य भाग की सामग्री के आधार पर संदेशों को रूट करती हैं, जिससे डाउनस्ट्रीम उपभोक्ताओं द्वारा अनावश्यक प्रसंस्करण समाप्त हो जाता है; SNS→SQS→Lambda पैटर्न प्रसारण और प्रसंस्करण के बीच टिकाऊ बफ़रिंग और दर नियंत्रण जोड़ता है; और क्रॉस-अकाउंट SQS वितरण कतार संसाधन नीतियों का उपयोग करके बहु-अकाउंट परिवेशों में केंद्रीकृत प्रकाशन/सदस्यता को सक्षम बनाता है। आगे हम Amazon API Gateway के REST, HTTP और WebSocket APIs का अध्ययन करेंगे।