Message queue: কেন লাগে এবং কীভাবে ফেল করে
Message queue সিস্টেমের এক অংশকে অপেক্ষা না করেই অন্য অংশে কাজ ধরিয়ে দিতে দেয়। Guarantee, failure কেস ও মূল টুলগুলো জানুন।

Message queue বসে producer (যে কাজ পাঠায়) আর consumer-এর (যে কাজ করে) মাঝে। Producer message ফেলে এগিয়ে যায়। Consumer প্রস্তুত হলে নেয়।
কেন ব্যবহার করবেন
- Decoupling: service-দের একই মুহূর্তে চালু থাকতে হয় না।
- Spike সামলানো: হঠাৎ traffic worker ভাঙার বদলে queue-তে জমে।
- Async কাজ: ইমেইল পাঠানো, ছবি ছোট করা, report বানানো ব্যাকগ্রাউন্ডে, তাই user-এর request দ্রুত ফেরে।
- Retry ও scale: আরও consumer যোগ করলে queue দ্রুত খালি হয়।
Delivery guarantee
- At-most-once: message হারাতে পারে, কখনো দ্বিগুণ হয় না।
- At-least-once: হারায় না, কিন্তু দুবার আসতে পারে। এটিই প্রচলিত, তাই consumer-কে idempotent হতে হবে (সেই পর্ব দেখুন)।
- Exactly-once: সাধারণভাবে খুব কঠিন; সাধারণত মানে at-least-once সাথে deduplication।
প্রক্রিয়া ব্যর্থ হলে
বাড়তে থাকা বিরতিতে কয়েকবার retry করুন। তবুও ব্যর্থ হলে message dead-letter queue (DLQ)-তে সরান যাতে অন্যদের না আটকায়, আর কাউকে দেখতে alert দিন। সবসময় ব্যর্থ হওয়া "poison message" consumer আটকে যাওয়ার ক্লাসিক কারণ।
Ordering
একটি queue ক্রম রাখতে পারে, কিন্তু সমান্তরাল অনেক consumer তা ভাঙে। Kafka-র মতো সিস্টেম partition-এর ভেতরে ক্রম রাখে, তাই এমন key (যেমন user_id) বাছুন যাতে সম্পর্কিত message একই partition-এ যায়।
টুল বাছাই
- RabbitMQ / SQS: task queue; message নেওয়া হলে শেষ। নমনীয় routing।
- Kafka: টেকসই log; message নির্দিষ্ট সময় থাকে আর অনেক consumer আবার পড়তে পারে। Event stream ও বিশাল volume-এ দারুণ।
সাবধান
Queue নীরবে বাড়ে। Queue-র গভীরতা এবং সবচেয়ে পুরোনো message-এর বয়স নজরে রাখুন।
মূল কথা: ধীর বা spike-যুক্ত কাজে queue নিন, ডুপ্লিকেট ধরে নিন, আর সবসময় dead-letter পথ রাখুন।
System Design সিরিজের 12 নম্বর পর্ব (মোট ১৫)। আগের পর্ব: Rate limiting: token bucket, sliding window ও বানানোর উপায়.


