SQS বনাম SNS বনাম Kinesis, আর Amazon MQ

এই লেসন শেষে তুমি পারবে

• SQS, SNS আর Kinesis Data Streams পাশাপাশি রেখে তুলনা করতে: push নাকি pull, পড়ার পর message-এর কী হয়, data কতদিন থাকে, ক্রম, duplicate, কয়জন consumer, কে কীভাবে scale করে, আর replay।
• কোনো scenario-র keyword দেখে ঠিক service (বা কয়েকটার জোড়া) বেছে নিতে: SQS FIFO, SNS + SQS fan-out, Kinesis + Data Firehose সহ, আর কখন উত্তর আসলে EventBridge বা Amazon MSK।
• Event-driven AWS-এর “মূল তিনজন” Lambda, SNS আর SQS কীভাবে একসাথে কাজ করে, dead-letter queue আর fan-out pattern সহ বুঝিয়ে বলতে।
• Amazon MQ কী, কোন কোন open protocol বোঝে (JMS, NMS, AMQP, STOMP, MQTT, OpenWire, WebSocket), আর কেন পুরোনো application নতুন করে না লিখে সরানোর বেলায় এটাই উত্তর, কিন্তু নতুন cloud-native app-এর বেলায় না, তা ব্যাখ্যা করতে।
• Amazon MQ-কে highly available করে সাজাতে: দুটো AZ জুড়ে shared EFS storage সহ ActiveMQ active/standby, তিন node-এর RabbitMQ cluster, আর server-এ চলা একটা broker-এর সীমাবদ্ধতা।

#পুরো chapter এক পাতায়

এই লেসন দিয়ে decoupling chapter শেষ হচ্ছে। Lesson 13.1-এ তিনটা model-এর পরিচয় হয়েছিল; 13.2 থেকে 13.6 পর্যন্ত প্রতিটা service গভীরে দেখেছ। এখানে ওদের পাশাপাশি দাঁড় করাব, যাতে পরীক্ষার প্রশ্নে বা design review-তে কয়েক সেকেন্ডে বেছে নিতে পারো, আর কেন বেছেছ সেটা যুক্তি দিয়ে বলতে পারো।

তিনটা model একবার মনে করিয়ে দিই (lesson 13.1):

• Queue (SQS): producer কাজ রেখে যায়; প্রতিটা message নেয় একজন consumer, কাজটা করে, তারপর delete করে।
• Publish/subscribe (SNS): publisher একটা message পাঠায়; প্রত্যেক subscriber নিজের একটা copy পায়, সাথে সাথে push হয়ে।
• Stream (Kinesis Data Streams): producer একটা log-এর শেষে record জুড়ে দেয়; অনেক consumer একই record পড়ে, প্রত্যেকে নিজের জায়গা থেকে, যতক্ষণ retention-এর সময় আছে।

Note-এ প্রতিটা service এক লাইনে বলা আছে:

• Amazon SQS application-কে decouple করে। Consumer-রা queue থেকে message টেনে নেয় (pull), আর একজন consumer সফলভাবে process করলে message চিরতরে delete হয়ে যায়। Worker tier দিয়ে কাজ করাতে এটা ব্যবহার করো (video processing, email পাঠানো)।
• Amazon SNS pub/sub model-এ কাজ করে, data সবার কাছে push করে দেয়। Standard topic কিছুই store করে না: পাঠানো হলেই message-এর গল্প শেষ। একটা event ঘটলে একসাথে অনেক service বা user-কে জানাতে হলে ব্যবহার করো (fan-out)।
• Amazon Kinesis বিশাল পরিমাণ streaming data সামলায়। পড়ার পরও data delete হয় না (retention আছে), আর একাধিক consumer একই data বারবার পড়তে পারে। Big data নিয়ে কাজ করলে, আর একই stream থেকে real-time-এ নানা রকম analytics চালাতে হলে এটা।

#SQS বনাম SNS বনাম Kinesis পাশাপাশি

Table-টা কীভাবে পড়বে:

• Push নাকি pull ঠিক করে দেয় কাকে তৈরি থাকতে হবে। SNS-এ subscriber-কে ঠিক তখনই পাওয়া যেতে হবে যখন SNS ডাকে; SQS আর standard Kinesis consumer-এ consumer নিজে তৈরি হলে চায়, তাই ধীর বা বন্ধ consumer শুধু কাজ জমায়।
• পড়ার পর কী হয়, এটাই সবচেয়ে গভীর পার্থক্য। Queue হলো করণীয় কাজের তালিকা: হয়ে গেলে কাটা পড়ে। Topic হলো ঘোষণা: পরে খুঁজে দেখার কিছু নেই। Stream হলো recording: পড়লে কিছুই বদলায় না, আর যে কেউ পিছিয়ে যেতে পারে।
• Capacity-র কারণে, সম্ভব হলে SQS আর SNS-ই ভালো: মাপজোখের কিছু নেই। Kinesis-এ তোমাকে provisioned shard বা on-demand mode বেছে নিতে হয় (lesson 13.5)।
• ক্রম-এর দাম সব জায়গাতেই throughput: FIFO queue আর topic-এর message group-এর সীমা আছে (lesson 13.3), আর Kinesis ক্রম রাখে শুধু একটা shard-এর ভেতরে।

#ভুল ধারণা: “SNS কোনো data store করে না”

#Data Firehose আর Amazon MQ কোথায় বসে

ওপরের table-টা পরীক্ষার চিরচেনা ত্রিভুজ। এই chapter-এর বাকি দুটো service দুটো ফাঁক পূরণ করে:

Firehose আছে lesson 13.6-এ; এর পরীক্ষার কৌশল হলো “প্রায় real time, code লাগে না, কোনো destination-এ তোলা”। Amazon MQ-এর জন্য নিচে আলাদা একটা অংশ আছে।

#বেছে নেওয়া: একটা সিদ্ধান্তের গাইড

1. এটা কি এমন চালু application, যেটা standard কোনো messaging protocol-এ কথা বলে?

   App যদি ActiveMQ বা RabbitMQ-এর মতো broker-এর সাথে JMS, NMS, AMQP, STOMP, MQTT বা OpenWire ব্যবহার করে, আর messaging code নতুন করে না লিখে AWS-এ সরাতে হয়: Amazon MQ। না হলে পরের ধাপে যাও।

2. প্রতিটা message একজন worker সামলাবে, নাকি সবাইকে দেখতে হবে?

   প্রতি message-এ একজন worker (job, task, process করার order): queue, SQS। Customer ধরে ক্রম বা ঠিক একবার process হওয়া জরুরি হলে: SQS FIFO। সবাইকে প্রতিটা message দেখতে হলে পরের ধাপে যাও।

3. প্রত্যেক receiver-কে এখনই পেতে হবে, আর পরে কেউ পড়তে না পারলেও চলবে?

   মানুষ আর endpoint-কে notification (email, SMS, mobile push, HTTP webhook): SNS। Receiver যদি এমন system হয়, যেটা বন্ধ থাকার সময়েও একটা message হারাতে পারবে না: SNS + SQS fan-out, প্রতিটা receiver-এর জন্য একটা queue।

4. কয়েকজন consumer-এর কি একই data নিজের গতিতে লাগবে, বা replay?

   বিশাল পরিমাণ event (clickstream, log, IoT reading, transaction), যেগুলো কয়েকটা স্বাধীন app পড়বে, real-time analytics, বা কোনো bug-এর পরে আবার process করা: Kinesis Data Streams। Stream-টা শুধু storage-এ তুলে দিতে হলে, কোনো code না লিখে: Data Firehose (সরাসরি, বা একটা Kinesis data stream থেকে পড়ে)।

5. Event কি আসছে AWS service বা SaaS app থেকে, rule দিয়ে route হবে?

   “কোনো EC2 instance-এর অবস্থা বদলালে…”, “কেউ এই API call করলে…”, partner SaaS-এর event, content দেখে অনেক target-এ rule, নির্দিষ্ট সময়ের event: Amazon EventBridge (chapter 19, lesson 19.5)। আর team যদি আগে থেকেই Apache Kafka চালায়, তাহলে managed উত্তর হলো Amazon Managed Streaming for Apache Kafka (lesson 17.7)।

#Keyword-এর মানচিত্র

কারণ পড়ার আগে বাস্তব কিছু scenario-তে নিজে চেষ্টা করো:

#মিলিয়ে বানানো pattern

বাস্তবের বেশিরভাগ system এই service-গুলোর একাধিক একসাথে ব্যবহার করে। নিচের চারটা pattern architecture-এ আর পরীক্ষার উত্তরে বারবার ফিরে আসে।

#SNS + SQS fan-out

একটা SNS topic-এ একবার publish করো, প্রতিটা consumer-এর জন্য একটা SQS queue subscribe করাও। SNS প্রতিটা queue-কে নিজের একটা copy দেয়; তারপর প্রতিটা queue তার consumer-কে দেয় buffer, retry, DLQ আর নিজের গতি। নতুন consumer মানে নতুন একটা queue, producer-এ কোনো বদল নেই। প্রতিটা queue-র access policy-তে topic-কে পাঠানোর অনুমতি দিতে হয়; অন্য account আর অন্য Region-এর subscription-ও চলে; subscription-এ filter policy দিলে ওই queue শুধু কিছু message পায়; আর SNS FIFO + SQS FIFO fan-out-এর পরেও ক্রম ধরে রাখে। এগুলো সব lesson 13.4-এ।

#SNS হয়ে S3 event

একটা S3 event notification (lesson 10.7) SQS, SNS বা Lambda-কে target করতে পারে, কিন্তু একটা prefix-এ একটা event type-এর গন্তব্য একটাই। একটা upload থেকে যখন কয়েকটা স্বাধীন কাজ শুরু করতে হয় (thumbnail, virus scan, indexing), তখন গন্তব্য হয় একটা SNS topic, যেটা কয়েকটা queue-তে ছড়িয়ে দেয়। বিকল্প হলো S3 event EventBridge-এ পাঠানো, যেটা অনেক target-এ route করতে পারে।

#Kinesis Data Streams + Data Firehose

একটা Kinesis data stream বিশাল পরিমাণ event একবার নেয়। Real-time consumer (Lambda, KCL দিয়ে বানানো একটা app, Managed Service for Apache Flink) এক সেকেন্ডের মধ্যে পড়ে dashboard আর alert-এর জন্য, আর Data Firehose একই stream পড়ে batch ধরে S3, Redshift বা OpenSearch-এ তুলে দেয়। Stream দেয় replay আর অনেক পাঠক; Firehose দেয় code ছাড়া storage (lesson 13.6)।

#Database-এর সামনে SQS

হঠাৎ ভিড়ের সময় queue ধাক্কাটা শুষে নেয়, আর worker (বা Lambda) লেখে database যতটা নিতে পারে সেই গতিতে। Producer দ্রুত থাকে, কিছু হারায় না, আর database কখনো traffic-এর দেয়াল দেখে না (lesson 13.1)।

#মূল তিনজন: Lambda, SNS আর SQS

Note এই তিনটাকে বলে AWS-এর event-driven architecture-এর ভিত্তি:

• SQS একটা message queue, যেটা application-কে decouple করে। এটা pull-ভিত্তিক: consumer (একটা EC2 worker, বা Lambda) queue থেকে message টেনে নেয়।
• SNS হলো pub/sub, আর push-ভিত্তিক: কোনো message publish হলেই প্রত্যেক subscriber (email, SMS, SQS, Lambda…) সাথে সাথে পেয়ে যায়।
• Lambda হলো serverless compute: কোনো event ঘটলে (যেমন SQS-এ নতুন message, বা SNS থেকে notification) সে নিজে থেকেই তোমার code চালায়।

পরীক্ষা যে সংশোধনটা পছন্দ করে: SQS Lambda-কে push করে না। Lambda service একটা event source mapping চালায়, যেটা queue poll করে (long polling দিয়ে), তোমার function-কে একটা batch দেয়, আর function সফল হলে message-গুলো delete করে। SNS-এর বেলায় উল্টো: SNS নিজেই function-টা invoke করে। Lambda আর event source mapping-এর বিস্তারিত chapter 15-এ (lesson 15.1)।

#এক অনুচ্ছেদে dead-letter queue

SQS, SNS বা Lambda যখন একটা message বারবার process করতে ব্যর্থ হয় (সর্বোচ্চ retry ফুরিয়ে যায়), তখন message-টাকে একটা আলাদা queue-তে সরিয়ে দেওয়া হয়, যাতে সেটা হারিয়ে না যায় আর বাকিদের আটকে না রাখে: এটাই dead-letter queue (DLQ)। পরে developer-রা এটা দেখে debug করে। SQS-এ এটা সেট করতে হয় মূল queue-র redrive policy দিয়ে, যেখানে DLQ-এর নাম আর maxReceiveCount থাকে; একটা message delete না হয়ে ততবার receive হলেই SQS সেটা সরিয়ে দেয়। FIFO queue-র DLQ-ও FIFO হতে হবে, DLQ থাকতে হবে একই account আর Region-এ, আর এর retention মূল queue-র চেয়ে লম্বা রাখা উচিত। সমস্যা ঠিক করার পর message-গুলো আবার মূল queue-তে redrive করা যায়। SNS-এর বেলায় DLQ হলো প্রতিটা subscription-এ জুড়ে দেওয়া একটা SQS queue। বিস্তারিত আর retention-এর ফাঁদটা আছে lesson 13.2-এ।

#এক অনুচ্ছেদে fan-out pattern

একটা SNS topic, তাতে কয়েকটা SQS queue subscribe করা। Topic-এ একটা message publish হলে সেটা একসাথে সব queue-তে ছড়িয়ে পড়ে, ফলে একই message দিয়ে সমান্তরালে একদম আলাদা কাজ করানো যায়: এক queue-র worker order-টা database-এ save করে, আরেকটার worker email পাঠায়। পরীক্ষার বাক্য: “a single event needs to trigger multiple independent workflows concurrently without data loss” → SNS + একাধিক SQS।

#Amazon MQ

#SQS আর SNS থাকতে broker কেন

SQS আর SNS হলো cloud-native service, যাদের আছে AWS-এর নিজস্ব API: এদের ডাকতে হয় HTTPS-এ, AWS SDK বা CLI দিয়ে। বাকি industry যে open messaging protocol কয়েক দশক ধরে ব্যবহার করে আসছে, সেগুলো এরা বোঝে না।

অনেক company এখনো নিজেদের অফিসে এমন application চালায়, যেগুলো Apache ActiveMQ, RabbitMQ বা IBM MQ-এর মতো একটা message broker-এর সাথে standard protocol আর API দিয়ে কথা বলে: JMS, NMS, AMQP, STOMP, MQTT, OpenWire, WebSocket। এমন application-কে SQS বা SNS-এ নিতে হলে প্রতিটা send আর receive নতুন করে লিখতে হবে, acknowledgement, transaction, topic আর selector কীভাবে চলে তা বদলাতে হবে, তারপর সব আবার test করতে হবে।

Amazon MQ হলো Apache ActiveMQ আর RabbitMQ-এর জন্য একটা managed message broker service। Broker চালানোর ঝামেলা (provisioning, patch, backup, failover) AWS নেয়, আর সে ঠিক ওই protocol-গুলোই বোঝে, তাই application নিজের code রেখে দেয়, বদলায় শুধু connection string। এর থাকার পুরো কারণ এটাই: note-এর ভাষায়, “SQS/SNS-এর জন্য নতুন করে লেখার সময় বা বাজেট নেই”।

#Open protocol-গুলো

সব endpoint-ই TLS ব্যবহার করে। Amazon MQ for RabbitMQ বোঝে AMQP 0-9-1 (port 5671), আর ২০২৫-এর নভেম্বর থেকে Amazon MQ-তে RabbitMQ 4.2 native AMQP 1.0-ও যোগ করেছে; সাথে আছে RabbitMQ-এর web console। (পাশের কথা: RabbitMQ 4.2 চলে Graviton-এর mq.m7g instance-এ, আর replicated queue বলতে শুধু quorum queue; পরীক্ষা version নিয়ে মাথা ঘামায় না।)

#দুটো engine

দুটো engine-ই একই broker-এ queue (point to point, SQS-এর মতো) আর topic বা exchange (publish/subscribe, SNS-এর মতো) দেয়। প্রচলিত broker সবসময় এভাবেই কাজ করেছে, আর এজন্যই একটা Amazon MQ broker পুরোনো setup-এর দুটো অংশেরই জায়গা নিতে পারে।

#এটা server-এ চলে

Amazon MQ managed, কিন্তু serverless না:

• তুমি একটা broker instance type বেছে নাও (যেমন test-এর জন্য mq.t3.micro, mq.m5.large আর তার চেয়ে বড়, বা Graviton-এর mq.m7g পরিবার) আর একটা deployment mode। টাকা দিতে হয় প্রতি broker-ঘণ্টা আর প্রতি GB-মাস storage ধরে, message চলুক বা না চলুক।
• একটা broker-এর সীমা বাঁধা: বড় instance type-এ ActiveMQ প্রতি wire-level protocol-এ ২,০০০ connection নেয় (micro-তে ৩০০), mq.m5 broker-এ storage 200 GB, আর default-এ প্রতি Region-এ ২০০টা broker।
• বেশি load সামলাতে বড় instance type-এ যেতে হয় (reboot দিয়ে বসে, active/standby-তে যেটা একটা ছোট্ট failover), বা একটা network of brokers বানাতে হয়। SQS আর SNS যেভাবে “scale” করে, এটা সেভাবে করে না, slide-এ এটা সরাসরিই বলা।
• Broker থাকে তোমার VPC-র subnet-এ, security group সহ। এটা private হতে পারে (অফিস থেকে VPN বা Direct Connect দিয়ে পৌঁছানো), বা public-ও করা যায়। Message at rest encrypt হয় KMS দিয়ে আর in transit TLS দিয়ে; ActiveMQ-এর user-রা username আর password দিয়ে, বা LDAP দিয়ে authenticate করে।

#High availability

Slide-এ ActiveMQ-এর ছবিটা এরকম: একটা AZ-এ একটা active broker, একই Region-এর আরেকটা AZ-এ একটা standby broker, দুজনেই storage হিসেবে Amazon EFS-এর সাথে যুক্ত, আর client একটা থেকে আরেকটায় failover করে।

• Single-instance (ActiveMQ বা RabbitMQ): একটা AZ-এ একটা broker, storage EBS-এ (ActiveMQ-এ চাইলে EFS)। সস্তা, development-এর জন্য ঠিক আছে; AZ বা broker বিকল হলে AWS ঠিক না করা পর্যন্ত broker পাওয়া যায় না।
• Active/standby (ActiveMQ): দুটো AZ-এ দুটো broker একটা redundant জোড়া হিসেবে, একটাই message store শেয়ার করে Amazon EFS-এ, যেটা data একাধিক AZ জুড়ে redundant রাখে। Active থাকে একটাই। সেটা বিকল হলে, বা সাপ্তাহিক maintenance window-তে, Amazon MQ standby-কে active করে, সে একই store খোলে, তাই persist হওয়া message হারায় না; reboot-এর failover-এ লাগে মাত্র কয়েক সেকেন্ড। প্রতিটা protocol-এর দুটো endpoint (-1 আর -2), আর client-কে দুটো দিয়েই failover transport ব্যবহার করতে হয়, যেমন failover:(ssl://b-…-1.mq…:61617,ssl://b-…-2.mq…:61617)।
• Cluster (RabbitMQ): একটা Network Load Balancer-এর পেছনে তিনটা AZ-এ তিনটা node, user, queue আর state শেয়ার করে; message node-গুলোর মধ্যে replicate হয়। Maintenance হয় একবারে একটা node ধরে, আর client-কে নিজে নিজে আবার connect করতে জানতে হয়।
• Network of brokers (ActiveMQ): কয়েকটা broker (প্রতিটা single বা active/standby) একসাথে জোড়া, scale-এর জন্য বা আলাদা জায়গার জন্য।

#Amazon MQ বনাম SQS আর SNS

#কোথায় গোলমাল হয়

#System design-এ messaging

• নতুন service-এ প্রথম পছন্দ SQS আর SNS: capacity নিয়ে ভাবনা নেই, যত ব্যবহার তত খরচ, আর integration-গুলো (Lambda, S3 event, ASG scaling, lesson 9.4-এর Beanstalk worker environment) আগে থেকেই আছে।
• প্রতি consumer-এ একটা queue, প্রতি event type-এ একটা topic। Domain event (“order placed”, “payment received”) SNS topic-এ publish করো, আর প্রতিটা consuming service-কে দাও নিজের SQS queue, নিজের DLQ সহ। তাহলে service-গুলো আলাদাভাবে deploy, scale আর নষ্টও হতে পারে।
• Data-র জন্য Kinesis, কাজের জন্য SQS। যে event কয়েকটা team বিশ্লেষণ করে, বা যেটা আবার চালাতে হতে পারে, সেটা যাবে stream-এ; যে কাজ একবারই করতে হবে, সেটা queue-তে। অনেক system-এ দুটোই থাকে, একই producer থেকে।
• Data lake-এর জন্য stream-এর শেষে Firehose, আর real-time ফলের জন্য Managed Service for Apache Flink বা Lambda (chapter 17)।
• সেতু হিসেবে Amazon MQ। Migration-এর deadline ধরতে পুরোনো app-কে Amazon MQ-তে তুলে বসাও, তারপর নতুন consumer বানাও SQS/SNS-এ, আর পুরোনো app অবসরে গেলে broker-টাও বন্ধ করো। AWS-এর migration pattern chapter 23-এ (server migration)।
• সব জায়গায় idempotency। Standard SQS, SNS, Kinesis আর broker-এর failover, সবাই একটা message একাধিকবার দিতে পারে; consumer-কে এমন হতে হবে যাতে দুবার চললেও ক্ষতি না হয়।
• জমা কাজের দিকে চোখ রাখো। Queue-র জন্য ApproximateNumberOfMessagesVisible, stream-এর জন্য GetRecords.IteratorAgeMilliseconds, আর প্রতিটা queue-র DLQ-এর গভীরতা: customer টের পাওয়ার আগেই এগুলো বলে দেয় কোনো consumer পিছিয়ে পড়ছে (CloudWatch, chapter 19)।
• পুরো account জুড়ে event: উৎস যখন AWS নিজেই (instance-এর অবস্থা বদল, CloudTrail-এ লেখা কোনো API call) বা কোনো SaaS partner, তখন EventBridge; event-processing-এর architecture-গুলো একসাথে আছে lesson 24.1-এ।

#নিজে করে দেখো

একই “order placed” event প্রতিটা service দিয়ে। Account 111122223333, Region ap-southeast-1; output ছোট করে দেখানো।

# 1. SQS: send, receive, delete (একজন consumer নিয়ে যায়)
aws sqs create-queue --queue-name orders-example
#   "QueueUrl": "https://sqs.ap-southeast-1.amazonaws.com/111122223333/orders-example"
Q=https://sqs.ap-southeast-1.amazonaws.com/111122223333/orders-example
aws sqs send-message --queue-url $Q --message-body '{"orderId":"A-1001","area":"Dhanmondi"}'
aws sqs receive-message --queue-url $Q --wait-time-seconds 20 --max-number-of-messages 10
#   "Messages": [{ "MessageId": "5fea7756-…", "ReceiptHandle": "AQEB…", "Body": "{\"orderId\":\"A-1001\",…}" }]
aws sqs delete-message --queue-url $Q --receipt-handle "AQEB…"
aws sqs receive-message --queue-url $Q --wait-time-seconds 5     # কিছুই নেই: চলে গেছে

# 2. SNS: একবার publish, প্রত্যেক subscriber একটা copy পায় (ওপরের queue-তে fan-out)
aws sns create-topic --name order-events-example
#   "TopicArn": "arn:aws:sns:ap-southeast-1:111122223333:order-events-example"
aws sns subscribe --topic-arn arn:aws:sns:ap-southeast-1:111122223333:order-events-example \
  --protocol sqs --notification-endpoint arn:aws:sqs:ap-southeast-1:111122223333:orders-example
aws sns subscribe --topic-arn arn:aws:sns:ap-southeast-1:111122223333:order-events-example \
  --protocol email --notification-endpoint ops@example.com
aws sns publish --topic-arn arn:aws:sns:ap-southeast-1:111122223333:order-events-example \
  --message '{"orderId":"A-1002"}'
#   "MessageId": "a1b2c3d4-…"   (queue-র access policy-তে এই topic-কে পাঠানোর অনুমতি লাগবে)

# 3. Kinesis: একটা record রাখো, দুবার পড়ো, একটা সময় থেকে replay
aws kinesis create-stream --stream-name order-stream-example --stream-mode-details StreamMode=ON_DEMAND
aws kinesis put-record --stream-name order-stream-example --partition-key Dhanmondi \
  --data '{"orderId":"A-1003"}' --cli-binary-format raw-in-base64-out
#   "ShardId": "shardId-000000000002", "SequenceNumber": "49654…"
IT=$(aws kinesis get-shard-iterator --stream-name order-stream-example --shard-id shardId-000000000002 \
  --shard-iterator-type AT_TIMESTAMP --timestamp 2026-10-26T09:00:00Z --query ShardIterator --output text)
aws kinesis get-records --shard-iterator $IT      # record এখনো আছে, যতবার খুশি

# 4. Amazon MQ: দুটো subnet-এ (দুটো AZ) একটা ActiveMQ active/standby broker, EFS storage
aws mq create-broker --broker-name orders-mq-example --engine-type ACTIVEMQ --engine-version 5.18 \
  --deployment-mode ACTIVE_STANDBY_MULTI_AZ --host-instance-type mq.m5.large --storage-type EFS \
  --no-publicly-accessible --auto-minor-version-upgrade \
  --subnet-ids subnet-0aaa1111example subnet-0bbb2222example --security-groups sg-0ccc3333example \
  --users Username=orders-admin,Password='use-a-long-secret-here',ConsoleAccess=true
#   "BrokerId": "b-1234abcd-56ef-78ab-90cd-1234567890ab"
aws mq describe-broker --broker-id b-1234abcd-56ef-78ab-90cd-1234567890ab \
  --query 'BrokerInstances[].Endpoints'
#   [ ["ssl://b-1234abcd-…-1.mq.ap-southeast-1.amazonaws.com:61617",
#      "amqp+ssl://b-1234abcd-…-1.mq.ap-southeast-1.amazonaws.com:5671",
#      "stomp+ssl://b-1234abcd-…-1.mq.ap-southeast-1.amazonaws.com:61614",
#      "mqtt+ssl://b-1234abcd-…-1.mq.ap-southeast-1.amazonaws.com:8883",
#      "wss://b-1234abcd-…-1.mq.ap-southeast-1.amazonaws.com:61619"],
#     ["ssl://b-1234abcd-…-2.mq.ap-southeast-1.amazonaws.com:61617", … ] ]
aws mq reboot-broker --broker-id b-1234abcd-56ef-78ab-90cd-1234567890ab   # client-এর failover দেখো

# 5. পরিষ্কার করো (broker অলস থাকলেও প্রতি ঘণ্টায় টাকা কাটে)
aws mq delete-broker --broker-id b-1234abcd-56ef-78ab-90cd-1234567890ab
aws kinesis delete-stream --stream-name order-stream-example
aws sns delete-topic --topic-arn arn:aws:sns:ap-southeast-1:111122223333:order-events-example
aws sqs delete-queue --queue-url $Q

পুরোনো app শুধু তার broker URL বদলে দুটো ssl:// endpoint-এর failover রূপ বসায়। ধাপ ৪-এর পার্থক্যটা খেয়াল করো: তোমাকে instance type, দুটো subnet আর একটা deployment mode বেছে নিতে হলো, যেগুলোর কোনোটাই SQS বা SNS কখনো জানতে চায়নি।

#সারসংক্ষেপ

মূল কথা

• SQS = queue, pull, প্রতি message-এ একজন consumer, process হলে delete, থাকে ১৪ দিন পর্যন্ত, capacity নিয়ে ভাবনা নেই, ক্রম শুধু FIFO-তে, প্রতি message-এ delay। Worker tier আর buffer।
• SNS = pub/sub, প্রতি topic-এ ১,২৫,০০,০০০ subscription পর্যন্ত push, standard topic কিছুই রাখে না (retry, subscription DLQ, FIFO archive আর replay হলো ব্যতিক্রম), ১,০০,০০০ topic পর্যন্ত, capacity নিয়ে ভাবনা নেই, ক্রমের জন্য FIFO topic। Notification আর fan-out।
• Kinesis Data Streams = stream, standard consumer টেনে নেয় (প্রতি shard-এ 2 MB/s ভাগাভাগি), enhanced fan-out push করে (প্রতি shard-এ প্রত্যেক consumer-এর 2 MB/s), record থেকে যায় ২৪ ঘণ্টা থেকে ৩৬৫ দিন, replay, ক্রম প্রতি shard-এ, provisioned বা on-demand। Real-time big data, analytics, ETL।
• Data Firehose stream-কে S3, Redshift, OpenSearch আর আরও জায়গায় তোলে, প্রায় real time, code ছাড়া, replay নেই। EventBridge AWS আর SaaS-এর event rule দিয়ে route করে (lesson 19.5); Amazon MSK হলো managed Kafka (lesson 17.7)।
• Pattern: SNS + SQS fan-out (একটা event, অনেক স্বাধীন workflow, কিছু হারায় না), S3 → SNS → SQS, Kinesis + Firehose, database-এর সামনে SQS।
• মূল তিনজন: SQS টানে, SNS ঠেলে দেয়, Lambda code চালায় (event source mapping দিয়ে Lambda SQS poll করে)। Poison message-এর জন্য redrive policy দিয়ে DLQ।
• Amazon MQ = managed ActiveMQ / RabbitMQ broker, বোঝে JMS, NMS, AMQP, STOMP, MQTT, OpenWire, WSS: চালু app নতুন করে না লিখে সরানোর উত্তর, নতুন cloud-native app-এর না। এতে queue আর topic দুটোই আছে, চলে broker instance-এ, SQS/SNS-এর মতো scale করে না।
• Amazon MQ HA: ActiveMQ-এ দুটো AZ-এ shared EFS storage সহ active/standby, সাথে failover transport; RabbitMQ-এ তিনটা AZ জুড়ে তিন node-এর cluster; single-instance-এ failover নেই।

নিজেকে যাচাই করো: SQS, SNS, Kinesis আর Amazon MQ-এর মধ্যে বেছে নেওয়া৩২টি প্রশ্ন