Sync বনাম Async, আর Amazon SQS

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

• Application-এর মধ্যে synchronous আর asynchronous communication-এর তফাত বলতে, আর হঠাৎ ভিড় এলে বা একটা service বিকল হলে tightly coupled system কেন ভোগে, সেটা বোঝাতে।
• AWS-এ decoupling-এর তিনটা model-এর নাম বলতে (SQS দিয়ে queue, SNS দিয়ে pub/sub, Kinesis দিয়ে streaming), আর প্রত্যেকটা একটা message নিয়ে কী করে, এক বাক্যে বলে দিতে।
• একটা SQS standard queue বর্ণনা করতে: সীমাহীন throughput আর backlog, retention (default ৪ দিন, ১৪ দিন পর্যন্ত), message-এর size (এখন ১ MiB), at-least-once delivery আর best-effort ordering।
• একটা message-কে SendMessage, ReceiveMessage (একবারে ১০টা পর্যন্ত) আর DeleteMessage পেরিয়ে অনুসরণ করতে, আর consumer crash করলে, duplicate এলে, বা message বেশি বড় কিংবা বেশি পুরোনো হলে কী হবে, আগেই বলে দিতে।
• SQS দিয়ে web tier আর worker tier আলাদা করতে, আর database-এর সামনে SQS-কে buffer হিসেবে বসাতে।
• Queue দেখে একটা Auto Scaling group দিয়ে worker fleet বাড়াতে-কমাতে, আর backlog per instance ও desired capacity হিসাব করতে।
• একটা queue সুরক্ষিত করতে: পথে HTTPS, জমা অবস্থায় SSE-SQS বা SSE-KMS, client-side encryption, IAM policy, আর অন্য account আর S3 বা SNS-এর জন্য SQS access policy।

#Application-রা কেন সবসময় একে অপরের জন্য বসে থাকবে না

একটার বেশি application চালানো শুরু করলেই তাদের একে অপরের সাথে কথা বলতে হয়। একটা online shop-এ থাকে buying service, যেটা order নেয়, আর shipping service, যেটা courier ঠিক করে; একটা payment app-এ থাকে একটা API, যেটা টাকা পাঠানোর request নেয়, আর একটা back office, যেটা হিসাব মেলায়। এদের কথা বলার উপায় দুটো।

#Synchronous communication

Synchronous মানে সরাসরি application থেকে application: buying service shipping service-কে সরাসরি call করে (একটা HTTP request, একটা RPC), আর নিজের user-কে উত্তর দেওয়ার আগে সেই উত্তরের জন্য অপেক্ষা করে।

ব্যাপারটা সহজ, আর যে call করছে সে সাথে সাথেই জানে কাজ হলো কিনা। কিন্তু এর দাম হলো tight coupling:

• দুজনকেই একই মুহূর্তে চালু থাকতে হবে। Shipping বন্ধ থাকলে বা নতুন করে deploy হতে থাকলে buying-ও ব্যর্থ হয়, যদিও buying-এর নিজের কোনো দোষ নেই।
• যে call করে, সে পেছনের সবচেয়ে ধীর service-এর মতোই ধীর। Shipping-এর দুই সেকেন্ড লাগলে প্রত্যেক ক্রেতাকেও দুই সেকেন্ড বসে থাকতে হয়।
• ভিড় সোজা ভেতরে ঢুকে পড়ে। Order একশো গুণ বেড়ে গেলে তার প্রত্যেকটা একসাথে গিয়ে পড়ে shipping-এর ঘাড়ে, তারপর database-এর ঘাড়ে। যেটা আগে ভাঙে, সে বাকিদেরও সাথে নিয়ে পড়ে।

#Asynchronous communication

Asynchronous (event-ভিত্তিক) মানে application থেকে queue, queue থেকে application: buying service order-টা একটা queue-তে লিখে রাখে, আর সাথে সাথে ক্রেতাকে উত্তর দিয়ে দেয়; shipping service তৈরি হলে queue থেকে order তুলে নেয়।

• Producer আর consumer-কে একই সময়ে চালু থাকতে হয় না। কাজটা queue ধরে রাখে।
• দুই পক্ষই চলে নিজের গতিতে। হঠাৎ ভিড় মানে এখন একটা লম্বা queue, বিভ্রাট না।
• দুই পক্ষই আলাদাভাবে বাড়ে-কমে। Buying service-কে না ছুঁয়েই shipping worker বাড়াতে পারো, আর কয়টা worker আছে, buying service তা জানেও না।

এর খরচ: ক্রেতাকে বলা হয় “order পেয়েছি”, “order পাঠানো হয়েছে” না, তাই product-টা এমনভাবে বানাতে হয় যাতে কাজটা একটু পরে শেষ হলেও চলে (order status page, notification), আর নজর রাখার মতো system-এ একটা জিনিস বাড়ে।

Slide-এ সেই চেনা প্রশ্নটা আছে: সাধারণত তুমি ১০টা video encode করো, হঠাৎ করতে হবে ১,০০০টা। Synchronous call-এ encoding server-গুলো ভেসে যায়, request ব্যর্থ হয়। মাঝখানে একটা queue থাকলে ১,০০০টা কাজ লাইনে অপেক্ষা করে, encoder-রা যত দ্রুত পারে তুলে নেয়, আর লাইন লম্বা হলে তুমি encoder বাড়াও। Note-এও একই গল্প, e-commerce-এর Black Friday দিয়ে (আমাদের জন্য ঈদের sale): queue ছাড়া worker tier চাপে crash করে আর নতুন order নেওয়া বন্ধ হয়ে যায়; queue থাকলে web tier “success” বলতেই থাকে, আর worker-রা পরে ধরে ফেলে।

#Decouple করার তিন উপায়: queue, pub/sub আর stream

Asynchronous communication-এর জন্য AWS তিনটা managed model দেয়, আর এই chapter-এ প্রত্যেকটা আছে। এরা তোমার application থেকে আলাদা, নিজে নিজেই বাড়ে-কমে।

Data Firehose (লেসন ১৩.৬) stream-কে storage-এ পৌঁছে দেয়, আর লেসন ১৩.৭-এ সবগুলো পাশাপাশি রাখা আছে, সাথে Amazon MQ, যেসব application আগে থেকেই standard messaging protocol-এ কথা বলে তাদের জন্য।

#Amazon SQS কী

Amazon Simple Queue Service (SQS) হলো একটা fully managed, serverless message queue। এখানে কোনো server, broker বা disk সামলাতে হয় না: তুমি একটা queue বানাও, API call দিয়ে তাতে message পাঠাও আর সেখান থেকে message নাও, আর AWS সেগুলো Region-এর কয়েকটা Availability Zone জুড়ে একাধিক জায়গায় জমা রাখে। এটা AWS-এর সবচেয়ে পুরোনো service: ২০০৪-এ public beta-য় আসে, ২০০৬ থেকে সবার জন্য চালু (লেসন ১.১), তাই slide-এর “১০ বছরের বেশি পুরোনো” এখন আসলে প্রায় ২০ বছর।

Microservice, distributed system আর serverless application-কে decouple করতেই এটা ব্যবহার হয়।

#Queue, producer আর consumer

• Producer queue-তে message পাঠায়। Producer অনেকগুলো হতে পারে।
• Queue প্রতিটা message জমা রাখে, যতক্ষণ না কোনো consumer সেটা delete করে।
• Consumer queue-কে poll করে, message নেয়, process করে, তারপর delete করে। Consumer-ও অনেকগুলো হতে পারে; প্রতিটা message একবারে তাদের একজনের কাছেই যায়।

Producer আর consumer হতে পারে EC2 instance, container, তোমার নিজের data centre-এর server, কিংবা Lambda function। শুধু SQS endpoint পর্যন্ত network আর সেটা call করার অনুমতি থাকলেই হলো।

#এক নজরে standard queue

SQS-এ queue দুই রকম: standard (এই লেসন আর পরেরটা) আর FIFO (লেসন ১৩.৩)। একটা standard queue-এর বৈশিষ্ট্য:

#Message পাঠানো (produce)

Producer SDK, CLI বা কোনো AWS service integration দিয়ে SendMessage call করে। Process করার জন্য একটা order পাঠাতে লাগে:

• body: {"order_id": 1001, "customer_id": "C-552", "amount": 1450},
• ইচ্ছে হলে message attribute (body-র বাইরের metadata, যেমন priority=normal), যেটা consumer body না খুলেই পড়তে পারে,
• queue-র URL, যেমন https://sqs.ap-southeast-1.amazonaws.com/111122223333/orders-example।

SQS message-টা জমা রেখে একটা message ID ফেরত দেয়। Message queue-তে থাকে যতক্ষণ না কোনো consumer সেটা delete করে, কিংবা retention-এর সময় শেষ হয়। SendMessageBatch এক call-এ ১০টা পর্যন্ত message পাঠায় (মোট ১ MiB পর্যন্ত), তাতে request আর টাকা দুটোই বাঁচে। চাইলে message visible হওয়ার আগে কিছুক্ষণ আটকেও রাখা যায় (delay queue আর timer, লেসন ১৩.২)।

#Message নেওয়া (consume)

একটা consumer একটা loop চালায়:

1. Poll করো

   ReceiveMessage call করো, একবারে ১০টা পর্যন্ত message চাও। Long polling থাকলে (লেসন ১৩.২) call-টা খালি হাতে সাথে সাথে না ফিরে একটা message-এর জন্য ২০ সেকেন্ড পর্যন্ত অপেক্ষা করে।

2. Process করো

   কাজটা করো: যেমন, order-টা একটা RDS database-এ insert করো, invoice email পাঠাও, ছবির মাপ বদলাও। Consumer যতক্ষণ কাজ করে, message-টা visibility timeout-এর জন্য (default ৩০ সেকেন্ড; লেসন ১৩.২) অন্য consumer-দের কাছ থেকে লুকানো থাকে।

3. Delete করো

   Message-এর receipt handle দিয়ে DeleteMessage call করো। কেবল এখনই message-টা চলে যায়। Receive করা মানে delete করা না: এই ধাপের আগে consumer crash করলে message আবার visible হয়, আর অন্য consumer সেটা পায়।

শেষ কথাটাই SQS-কে নিরাপদ বানায়: কেউ নিশ্চিত না করা পর্যন্ত যে কাজ শেষ, message সরানো হয় না।

#অনেক consumer: at least once, best-effort ক্রম

একই queue-কে কয়েকটা consumer poll করতে পারে। প্রত্যেকে আলাদা আলাদা message পায়, সবাই একসাথে কাজ করে, আর যে যেটা process করল, সেটা delete করে। প্রতি সেকেন্ডে আরও বেশি message process করতে চাইলে consumer horizontally বাড়াও: instance, container বা Lambda concurrency যোগ করো। Producer-এর দিকে কিছুই বদলায় না।

SQS অনেক server-এ message ছড়িয়ে রাখে বলে standard queue-এর দুটো বৈশিষ্ট্য আসে:

• At-least-once delivery। মাঝে মাঝে একটা message দুবার আসে (যেমন, তুমি delete করার সময় copy রাখা কোনো server নাগালে ছিল না)। Consumer-কে idempotent বানাও: একই message দুবার process করলে ফল যেন একবারের মতোই হয়। Order ID একটা unique constraint সহ রাখো, কিংবা টাকা কাটার আগে দেখে নাও “আগেই কাটা হয়েছে কি?”।
• Best-effort ordering। SQS পাঠানোর ক্রম রাখার চেষ্টা করে, কিন্তু message এলোমেলো ক্রমে আসতে পারে। ক্রম জরুরি হলে (bank transaction, শেয়ার কেনাবেচা) বা duplicate একেবারেই চলবে না এমন হলে FIFO queue নাও (লেসন ১৩.৩)।

#Application tier আলাদা করা

#Web tier আর worker tier

Slide-এ চেনা ছবিটা আঁকা: একটা Auto Scaling group-এ front-end web application request নেয় আর SendMessage call করে; নিজের আলাদা Auto Scaling group-এ একটা back-end processing application ReceiveMessage call করে; মাঝখানে একটা SQS queue, যেটা কার্যত অসীম পর্যন্ত বাড়তে পারে।

• Web tier দ্রুত থাকে, কারণ সে শুধু তাড়াতাড়ির অংশটুকু করে (যাচাই, queue-তে রাখা, উত্তর)।
• Worker tier ধীর অংশটা করে (video processing, invoice, payment, email) নিজের গতিতে, সেই কাজের জন্য বেছে নেওয়া instance type-এ (যেমন video-র জন্য GPU instance)।
• প্রত্যেক tier নিজের metric দেখে বাড়ে-কমে: web tier request দেখে, worker tier queue দেখে।

এটাই note-এর e-commerce উদাহরণ। SQS না থাকলে Black Friday-র ভিড়ে worker tier crash করতে পারে, তখন নতুন order দেওয়াই যায় না। SQS থাকলে web tier প্রতিটা order queue-তে পাঠিয়ে user-কে “success” দেখায়; worker-রা নিজের সামর্থ্য মতো order টেনে নেয়; worker-এর ওপর চাপ কখনো user পর্যন্ত পৌঁছায় না। Elastic Beanstalk-এর worker environment (লেসন ৯.৪) হুবহু এই pattern, প্যাকেট করে দেওয়া।

#Database-এর সামনে buffer হিসেবে SQS

Slide-এ সমস্যাটার আরেকটা রূপও আছে। একটা Auto Scaling group-এর application transaction সরাসরি database-এ লেখে (RDS, Aurora বা DynamoDB)। Load খুব বেশি হলে database-এর connection বা লেখার ক্ষমতা ফুরিয়ে যায়, insert ব্যর্থ হয়, আর কিছু transaction হারিয়ে যেতে পারে।

সামনে একটা queue বসাও: application প্রতিটা transaction queue-তে রাখে (SendMessage), আর একদল worker সেটা queue থেকে তোলে (ReceiveMessage), তারপর এমন গতিতে insert করে, যেটা database সইতে পারে। ভিড়টা queue শুষে নেয়; কিছুই হারায় না; database পায় স্থির load। বিনিময়ে লেখাটা আর সাথে সাথে হয় না, তাই এটা মানায় এমন লেখায়, যেটা user পরের সেকেন্ডেই পড়ে দেখতে চায় না (order, log, হিসাব মেলানোর payment), এমন profile update-এ না, যেটা user সাথে সাথে দেখতে চায়।

#Auto Scaling group দিয়ে consumer বাড়ানো-কমানো

Queue ঠিক বলে দেয় কতটা কাজ অপেক্ষায় আছে, worker বাড়ানো-কমানোর জন্য এর চেয়ে ভালো সংকেত হয় না।

#Note-এর উপায়: queue length-এর ওপর একটা alarm

Note-এর উদাহরণ: হঠাৎ ১০,০০০টা message এল, কিন্তু EC2 instance মাত্র ২টা, তাই process করতে অনেক সময় লাগবে। কাজটা চলে এভাবে:

1. SQS CloudWatch-এ ApproximateNumberOfMessagesVisible metric পাঠায়, মানে কতগুলো message process হওয়ার জন্য তৈরি (slide একে বলে queue length, ApproximateNumberOfMessages, queue attribute হিসেবে একই সংখ্যা)।
2. একটা সীমা পেরোলে, যেমন ১,০০০, একটা CloudWatch alarm বাজে।
3. Alarm-টা Auto Scaling group-এর একটা scaling policy চালু করে, যেটা instance বাড়ায় (scale out)। Queue ছোট হলে আরেকটা alarm সেগুলো সরায় (scale in)।

এটা কাজ করে, আর slide-এ এটাই আঁকা। তবে দুটো সংশোধন আছে। Note-এ policy-টাকে বলা হয়েছে “Step Tracking”: এমন কিছু নেই। Policy-র ধরন হলো step scaling (আর simple scaling) আর target tracking (লেসন ৬.৫)। আর raw queue length-এর ওপর বাঁধা একটা সীমার দুর্বলতা আছে: আগে থেকে কয়টা worker আছে, সেটা সে জানে না। Instance যোগ করলে queue length সেই অনুপাতে কমে না, তাই queue কমতে থাকলেও alarm লাল থেকে যায় আর instance যোগ করতেই থাকে, কিংবা সীমার আশেপাশে ওঠানামা করে দোল খায়।

#ভালো উপায়: backlog per instance

AWS-এর পরামর্শ: backlog per instance-এর ওপর একটা target tracking policy।

• Backlog per instance = visible message ÷ চালু (InService) instance-এর সংখ্যা।
• Target (গ্রহণযোগ্য backlog per instance) = একটা message সর্বোচ্চ যতক্ষণ অপেক্ষা করতে পারে ÷ একটা instance-এর একটা message process করতে গড়ে যত সময় লাগে।

AWS-এর নিজের উদাহরণ: ১০টা instance, ১,৫০০টা visible message, প্রতি message-এ ০.১ সেকেন্ড, অপেক্ষা সর্বোচ্চ ১০ সেকেন্ড। Target = ১০ ÷ ০.১ = প্রতি instance-এ ১০০টা message। এখন backlog per instance ১,৫০০ ÷ ১০ = ১৫০, target-এর ওপরে, তাই group বেড়ে হয় ১,৫০০ ÷ ১০০ = ১৫টা instance।

এটা আর কোনো script দিয়ে custom metric হিসেবে publish করতে হয় না: target tracking policy SQS-এর metric আর group-এর GroupInServiceInstances metric থেকে metric math দিয়েই হিসাব করে নেয়। Policy-টা লেসন ৬.৫-এ দেখানো আছে; এখানে দেখো fleet-এর ওপর সেটা কী করে।

নিজের সংখ্যা দিয়ে চেষ্টা করো, note-এর ১০,০০০টা message আর ২টা instance সহ:

Production-এ যে দুটো খুঁটিনাটি জরুরি:

• Scale-in-এ message নিরাপদ। কোনো instance হাতে message নিয়ে বন্ধ হলে, message-টা তো কখনো delete হয়নি, তাই visibility timeout-এর পর ফিরে আসে। লম্বা কাজের জন্য worker ব্যস্ত থাকার সময় instance scale-in protection চালু রাখো, যাতে group আগে অলস worker-গুলো বন্ধ করে।
• Lambda নিজেই বাড়ে। Consumer যদি SQS event source mapping সহ একটা Lambda function হয়, Lambda নিজেই queue poll করে আর concurrency বাড়ায়; সেখানে কোনো Auto Scaling group নেই (serverless chapter, লেসন ১৫.১)।

#SQS-এর নিরাপত্তা

#Encryption

Note-এ SSE-SQS-কে KMS-এর নিচে রাখা হয়েছে; ঠিকভাবে বললে, শুধু SSE-KMS-ই AWS KMS ব্যবহার করে। SSE-SQS-এর key SQS নিজের ভেতরেই সামলায়। যেটাই নাও, SSE encrypt করে message-এর body; queue-র নাম, message attribute, message ID আর metric encrypt হয় না, তাই attribute-এ গোপন কিছু রেখো না। Encryption চালু করার পরে পাঠানো message-এই কেবল সেটা খাটে। KMS নিজে আছে লেসন ২১.২-এ; S3-এর জন্য SSE-S3 বনাম SSE-KMS-এর একই বাছাই দেখেছিলে লেসন ১০.৮-এ।

#Access control: IAM policy আর SQS access policy

Queue কে call করতে পারবে, তা ঠিক করে দুই রকম policy (লেসন ২.১ আর ২.২):

Note-এর পরীক্ষার কৌশল, slide-ও একই কথা বলে: “অন্য একটা AWS account-কে তোমার queue-তে message পাঠাতে দাও” বা “S3-কে (বা SNS-কে) তোমার queue-তে message পাঠাতে দাও” → SQS access policy। অন্য account-এর বেলায় দুই পক্ষকেই রাজি হতে হয়: queue policy account B-কে অনুমতি দেয়, আর account B-র নিজের IAM policy তার user বা role-কে SQS call করার অনুমতি দেয়।

একটা queue policy, যেটা একটা S3 bucket-কে তার event notification (লেসন ১০.৭) queue-তে পাঠাতে দেয়, আর শুধু ওই bucket-কেই:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowS3Events",
    "Effect": "Allow",
    "Principal": { "Service": "s3.amazonaws.com" },
    "Action": "sqs:SendMessage",
    "Resource": "arn:aws:sqs:ap-southeast-1:111122223333:orders-example",
    "Condition": {
      "ArnLike": { "aws:SourceArn": "arn:aws:s3:::uploads-example" },
      "StringEquals": { "aws:SourceAccount": "111122223333" }
    }
  }]
}

Condition-গুলো জরুরি: এগুলো ছাড়া যেকোনো account-এর যেকোনো bucket S3-এর মাধ্যমে তোমার queue-তে পাঠাতে পারত (“confused deputy” সমস্যা)। আরেকটা ফাঁদ: queue যদি AWS managed key alias/aws/sqs দিয়ে SSE-KMS ব্যবহার করে, S3 আর SNS তাতে পাঠাতে পারে না, কারণ ওই key-এর policy বদলে ওদের ব্যবহারের অনুমতি দেওয়া যায় না। এমন একটা customer managed key নাও, যার key policy service-টাকে kms:GenerateDataKey আর kms:Decrypt-এর অনুমতি দেয়।

শেষে network-এর কথা: NAT gateway ছাড়া private subnet-এর worker-রাও একটা interface VPC endpoint (AWS PrivateLink) দিয়ে SQS-এ পৌঁছাতে পারে, আর queue policy দিয়ে বাধ্য করা যায় যে request ওই পথেই আসতে হবে (aws:SourceVpce)। বিস্তারিত লেসন ২২.২-এ।

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

#System design-এ SQS

• Web tier / worker tier। Front end শুধু যাচাই করে queue-তে রাখে; ধীর কাজ (video encoding, invoice file, email, ছবির মাপ বদলানো) চলে worker-এ, যেগুলো backlog দেখে বাড়ে-কমে। User দ্রুত উত্তর পায়, worker-এর বিভ্রাট কখনো টেরও পায় না।
• Database-এর জন্য লেখার buffer। হঠাৎ একগাদা লেখা সামলাও, যাতে RDS, Aurora বা DynamoDB-র মাপ হয় স্বাভাবিক load-এর, সবচেয়ে ব্যস্ত মুহূর্তের না।
• Microservice decoupling। Service-রা একে অপরকে call না করে queue-তে কাজ রাখে, তাই একটা service-এর deployment বা বিকল বাকিদের মধ্যে ছড়ায় না।
• Event-এর গন্তব্য। S3 event notification (লেসন ১০.৭), SNS topic (লেসন ১৩.৪) আর EventBridge rule (লেসন ১৯.৫) একটা queue-তে পৌঁছে দিতে পারে, তাই event-এর ঝাঁক নিয়ন্ত্রিত গতিতে process হয়।
• খরচ আর Spot। Worker হারালেও message টিকে থাকে বলে queue worker Spot Instance-এর জন্য দারুণ মানানসই: interruption মানে শুধু message-টা অন্য কেউ process করবে (লেসন ৪.৪)।
• যা এটা না। SQS database না (query নেই, retention সর্বোচ্চ ১৪ দিন), broadcast system না (তার জন্য SNS), আর replay করার মতো log-ও না (তার জন্য Kinesis)।

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

একটা queue বানাও, একটা message পাঠাও আর নাও, তার attribute দেখো, আর queue-র metric পড়ো। Output ছোট করে দেখানো।

# 1. Create a standard queue: 4-day retention by default; set 14 days (in seconds)
aws sqs create-queue --queue-name orders-example \
  --attributes MessageRetentionPeriod=1209600 --region ap-southeast-1
# { "QueueUrl": "https://sqs.ap-southeast-1.amazonaws.com/111122223333/orders-example" }

Q=https://sqs.ap-southeast-1.amazonaws.com/111122223333/orders-example

# 2. Check the defaults: visibility 30 s, max size 1 MiB, SSE-SQS on
aws sqs get-queue-attributes --queue-url $Q --attribute-names All
# "VisibilityTimeout": "30", "MaximumMessageSize": "1048576",
# "MessageRetentionPeriod": "1209600", "SqsManagedSseEnabled": "true", ...

# 3. Produce: a body plus one message attribute
aws sqs send-message --queue-url $Q \
  --message-body '{"order_id":1001,"customer_id":"C-552","amount":1450}' \
  --message-attributes 'priority={DataType=String,StringValue=normal}'
# { "MD5OfMessageBody": "6b1e1c...", "MessageId": "5fea7756-0ea4-451a-a703-a558b933e274" }

# 4. Consume: up to 10 messages, waiting up to 20 s (long polling)
aws sqs receive-message --queue-url $Q --max-number-of-messages 10 \
  --wait-time-seconds 20 --message-attribute-names All
# { "Messages": [{ "MessageId": "5fea7756-...", "ReceiptHandle": "AQEBzbVv...",
#     "Body": "{\"order_id\":1001,...}" }] }

# 5. Delete it with the receipt handle (not the message ID)
aws sqs delete-message --queue-url $Q --receipt-handle "AQEBzbVv..."

# 6. Look at the backlog: the attribute, and the CloudWatch metric the ASG uses
aws sqs get-queue-attributes --queue-url $Q \
  --attribute-names ApproximateNumberOfMessages ApproximateNumberOfMessagesNotVisible
aws cloudwatch get-metric-statistics --namespace AWS/SQS \
  --metric-name ApproximateNumberOfMessagesVisible \
  --dimensions Name=QueueName,Value=orders-example \
  --start-time 2026-10-26T00:00:00Z --end-time 2026-10-26T01:00:00Z \
  --period 300 --statistics Average

# 7. Allow account 444455556666 to send (queue policy from a file)
aws sqs set-queue-attributes --queue-url $Q --attributes file://policy.json

# 8. Switch to SSE-KMS with your own key, then clean up
aws sqs set-queue-attributes --queue-url $Q \
  --attributes KmsMasterKeyId=alias/orders-key,KmsDataKeyReusePeriodSeconds=300
aws sqs delete-queue --queue-url $Q

policy.json-এ থাকে {"Policy": "<queue policy, escape করা JSON string হিসেবে>"}। ধাপ ৫ বাদ দিয়ে ধাপ ৪ দুবার চালাও, মাঝে ৩০ সেকেন্ড অপেক্ষা করো: একই message নতুন একটা receipt handle নিয়ে ফিরে আসে। এটাই visibility timeout, পরের লেসনের বিষয়।

#সারসংক্ষেপ

মূল কথাগুলো

• Synchronous (application থেকে application) service-দের বেঁধে ফেলে: দুজনকেই চালু থাকতে হয়, caller সবচেয়ে ধীরজনের মতো ধীর, ভিড় সোজা ভেতরে ঢোকে। Asynchronous (application থেকে queue, queue থেকে application) প্রত্যেক পক্ষকে নিজের মতো চলতে, বিকল হতে আর বাড়তে-কমতে দেয়।
• তিনটা model: queue (SQS), প্রতিটা message একজন consumer-এর, process শেষে মুছে যায়; pub/sub (SNS), প্রত্যেক subscriber-কে একটা করে copy ঠেলে পাঠানো; stream (Kinesis), record থেকে যায়, অনেক reader আবার পড়তে পারে। লেসন ১৩.৪, ১৩.৫, ১৩.৭।
• SQS standard: fully managed, serverless, প্রায় সীমাহীন throughput, সীমাহীন backlog, retention default ৪ দিন, ১ মিনিট থেকে ১৪ দিন, message ১ MiB পর্যন্ত (আগস্ট ২০২৫-এর আগে ২৫৬ KB; বড় হলে S3 pointer), at-least-once delivery, best-effort ordering, কম latency।
• পাঠাতে SendMessage; নিতে ReceiveMessage (১০টা পর্যন্ত); process শেষে DeleteMessage। Receive করলে message শুধু লুকায়, মোছে না, তাই crash মানে আবার deliver। Consumer-কে idempotent হতে হবে।
• Web আর worker tier decouple করো, database-এর লেখা buffer করো, যাতে ভিড় মানে হয় লম্বা queue, হারানো transaction না।
• Queue-র metric ApproximateNumberOfMessagesVisible দেখে Auto Scaling group দিয়ে worker বাড়াও-কমাও; সবচেয়ে ভালো backlog per instance-এর ওপর target tracking (target = গ্রহণযোগ্য অপেক্ষা ÷ প্রতি message-এর সময়)। “Step Tracking” কোনো policy-র ধরন না।
• নিরাপত্তা: পথে HTTPS; জমা অবস্থায় SSE-SQS (default, বিনা খরচে) বা SSE-KMS (তোমার key policy, CloudTrail, KMS-এর খরচ); পুরো নিয়ন্ত্রণ চাইলে client-side encryption। নিজের account-এর জন্য IAM policy; অন্য account আর queue-তে পাঠানো S3 / SNS-এর জন্য SQS access policy (aws:SourceArn সহ, আর queue SSE-KMS হলে customer managed KMS key)।

নিজেকে যাচাই করো: Sync বনাম Async আর Amazon SQS৩১টি প্রশ্ন