মনে করুন, একটি ই-কমার্স অ্যাপ্লিকেশন। কোনো ইউজার যখন একটি অর্ডার প্লেস করে, তখন ব্যাকএন্ডে একগুচ্ছ কাজ সম্পন্ন করতে হয়:
- কাস্টমারকে অর্ডার কনফার্মেশন ইমেইল পাঠাতে হবে।
- কনফার্মেশন SMS পাঠাতে হবে।
- ইনভেন্টরি বা স্টক আপডেট করতে হবে।
- অ্যানালিটিক্স ডাটা আপডেট করতে হবে।
এই সবগুলো কাজ যদি অর্ডার হিট হওয়ার সাথে সাথেই সিঙ্ক্রোনাসলি (Synchronously) করতে চাই, তবে বেশ কিছু বড় সমস্যার মুখোমুখি হতে হবে:
- রেসপন্স টাইম অনেক বেশি বেড়ে যাবে এবং ইউজারকে স্ক্রিনে ওয়েট করে বসে থাকতে হবে।
- ৩র্ড পার্টি ইমেইল বা SMS সার্ভিস ডাউন থাকলে পুরো অর্ডারটিই ফেল (Fail) মারবে।
- ডাটাবেসের মধ্যে ইনকনসিস্টেন্সি (Inconsistency) তৈরি হতে পারে।
এখন নিজেকে একটা প্রশ্ন করুন—ইউজার যখন পে পেজের "Confirm Order" বাটনে ক্লিক করে, তখন কি সে সাথে সাথে ইমেইল পাওয়া পর্যন্ত অপেক্ষা করতে চায়? নাকি ১ সেকেন্ডের মধ্যে "Order Successful" মেসেজ স্ক্রিনে দেখতে চায়?
অবশ্যই ইউজার সাথে সাথে রেসপন্স দেখতে চায়! ইমেইল বা SMS ১ মিনিট পরে গেলেও কাস্টমারের কোনো সমস্যা নেই।
এই যে ব্যাকগ্রাউন্ডে ভারী কাজগুলোকে সরিয়ে দিয়ে ইউজারকে দ্রুত রেসপন্স দেওয়া—এই সমস্যার সবচেয়ে চমৎকার সমাধান হলো Message Broker।
Message Broker কী? 📬
Message Broker ব্যাপারটিকে একটি পোস্ট অফিসের সাথে তুলনা করা যেতে পারে।
আগে দূরে কোনো চিঠি বা বার্তা পৌঁছাতে পোস্ট অফিস ব্যবহার করা হতো। আপনি পোস্ট বক্সে চিঠি ফেলে দিয়ে চলে আসতেন এবং নিজের অন্যান্য কাজ শুরু করে দিতেন—চিঠি গন্তব্যে পৌঁছানো পর্যন্ত আপনি পোস্ট অফিসে দাঁড়িয়ে থাকতেন না!
Message Broker ঠিক একই ধারণায় কাজ করে। মূল অ্যাপ্লিকেশন সার্ভিসটি মেসেজ ব্রোকারের কাছে একটি মেসেজ (বা ইভেন্ট) পুশ করে দিয়ে সাথে সাথে ইউজারকে রেসপন্স জানিয়ে দেয়। পরবর্তীতে ব্যাকগ্রাউন্ডের অন্যান্য Consumer সার্ভিসগুলো সেই মেসেজটি রিসিভ করে আস্তেধীরে প্রসেস করতে থাকে।
বর্তমানে ব্যাকএন্ড ইঞ্জিনিয়ারিংয়ে দুটি মেসেজ ব্রোকার সবচেয়ে বেশি ব্যবহৃত হয়: RabbitMQ এবং Apache Kafka।
RabbitMQ: Smart Broker, Dumb Consumer 🐇
RabbitMQ হলো একটি ঐতিহ্যবাহী ও বহুল ব্যবহৃত Message Queue সিস্টেম। এটি মূলত AMQP (Advanced Message Queuing Protocol) স্ট্যান্ডার্ড অনুসরণ করে।
এর মেকানিজম বেশ সহজ—এটি Push-based Model মেনে চলে। প্রডিউসার মেসেজ পাঠালে ব্রোকার নিজে থেকে কনজিউমারের কাছে মেসেজ পুশ করে। কনজিউমার কাজ শেষে Acknowledgment (ACK) পাঠালে ব্রোকার কিউ থেকে মেসেজটি চিরতরে মুছে ফেলে।
💡 কখন RabbitMQ ব্যবহার করবেন?
- Task Queue & Background Jobs: ইমেইল পাঠানো, ছবি/ভিডিও প্রসেসিং, PDF রিপোর্ট জেনারেট করার মতো কাজের জন্য।
- Complex Message Routing: নির্দিষ্ট শর্তে মেসেজ পাঠাতে চাইলে (যেমন: "শুধু VIP কাস্টমারদের প্রাইওরিটি ইমেইল কিউতে পাঠাও")।
- Guaranteed Delivery: প্রতিটি মেসেজ যেন মিস না হয় এবং নিখুঁতভাবে অন্তত একবার প্রসেস হয়ে মুছে যায়।
Apache Kafka: Dumb Broker, Smart Consumer 🚂
Apache Kafka কিন্তু সাধারণ Message Queue নয়—এটি একটি Distributed Event Streaming Platform।
ক্যাফকা মেসেজকে মুছে ফেলার বদলে ডিস্কে একটি Append-only Commit Log হিসেবে সংরক্ষণ করে রাখে। প্রডিউসার ইভেন্ট রাইট করে যায়, আর কনজিউমার নিজের অফসেট (Offset) ট্র্যাক করে নিজের গতিতে ডাটা রিড (Pull Model) করতে থাকে। মেসেজ পড়ার পরও ক্যাফকা থেকে ডাটা মুছে যায় না (নির্ধারিত Retention সময় পর্যন্ত সংরক্ষিত থাকে)।
💡 কখন Apache Kafka ব্যবহার করবেন?
- High Volume Real-time Event Streaming: প্রতি সেকেন্ডে লাখ লাখ ইভেন্ট বা লগ প্রসেস করতে হলে (যেমন: উবার রাইড ট্র্যাকিং, ক্রেডিট কার্ড ফ্রড ডিটেকশন)।
- Message Replayability: পুরানো ইভেন্ট আবার নতুন করে প্রসেস বা রিঅ্যালাইজ করার প্রয়োজন হলে।
- Multiple Independent Consumers: একই ইভেন্ট স্ট্রিম থেকে আলাদা আলাদা মাইক্রোসার্ভিস (Analytics, Fraud Detection, Notification) স্বাধীনভাবে ডাটা রিড করতে চাইলে।
RabbitMQ vs Apache Kafka: মুখোমুখি তুলনা ⚖️
| বৈশিষ্ট্য | RabbitMQ 🐇 | Apache Kafka 🚂 |
|---|---|---|
| আর্কিটেকচার টাইপ | Traditional Message Queue | Distributed Event Streaming Log |
| ডাটা মডেল | Queue (Message প্রসেস হলে মুছে যায়) | Log Stream (মেসেজ ডিস্কে সেভ থাকে) |
| মেসেজ ডেলিভারি | Push Model (Broker → Consumer) | Pull Model (Consumer ← Broker) |
| Throughput | হাজার হাজার মেসেজ/সেকেন্ড | লাখ লাখ মেসেজ/সেকেন্ড |
| Message Routing | অত্যন্ত শক্তিশালী (Exchange, Routing Keys) | সিম্পল (Topic & Partition ভিত্তিক) |
| Replayability | সাপোর্ট করে না (ACK পেলে ডিলিট) | চমৎকার (Offset পিছিয়ে আবার পড়া যায়) |
Real-World Example: অর্ডার প্রসেসিং ফ্লো
-
RabbitMQ ফ্লো:
- ইউজার অর্ডার দিল → Order Service মেসেজ পাঠাল RabbitMQ-তে → ইউজারকে সাথে সাথে Success রেসপন্স দেওয়া হলো।
- ব্যাকগ্রাউন্ডে Email Worker বা SMS Worker মেসেজ পিক করল → ইমেইল পাঠিয়ে দেওয়ার পর RabbitMQ মেসেজটি ডিলিট করে দিল।
-
Kafka ফ্লো:
- ইউজার রাইড বুক করল → Ride Service Kafka Topic (
ride-events)-এ ইভেন্ট রাইট করল। - Location Tracker Service, Billing Service, এবং Analytics Engine—তিনটি স্বাধীন সার্ভিস একই সাথে ক্যাফকা টপিক থেকে প্যারালালি ডাটা রিড করে নিজেদের কাজ সম্পন্ন করল।
- ইউজার রাইড বুক করল → Ride Service Kafka Topic (
বটম লাইন
RabbitMQ এবং Kafka দুটিই অসাধারণ প্রযুক্তি—তবে তারা ভিন্ন সমস্যার সমাধান করে। যদি আপনার নির্দিষ্ট কাজ প্রসেস করার জন্য নির্ভরযোগ্য Task Queue দরকার হয় যেখানে মেসেজ প্রসেস হয়ে মুছে গেলেই চলে, তবে RabbitMQ বেছে নিন। আর যদি আপনার প্রতি সেকেন্ডে বিশাল আকারের ইভেন্ট স্ট্রিম প্রসেস ও অ্যানালিটিক্সের প্রয়োজন হয়, তবে Apache Kafka হলো সেরা পছন্দ।
আপনার প্রজেক্টে ব্যাকগ্রাউন্ড টাস্ক বা ইভেন্ট প্রসেস করার জন্য কোন মেসেজ ব্রোকার ব্যবহার করছেন? কমেন্টে জানান! 👇
Top comments (1)
Answering your question: at work I use SQS + Sidekiq for background jobs, which is basically the RabbitMQ-style task-queue case you describe. I reached for Kafka when one payment event had to trigger five independent downstream services. That's your "multiple independent consumers" point, and it's exactly where queues stopped working for me.
One thing I'd add under Replayability: with Kafka you can add a new consumer months later and have it read the topic from the start (as far back as retention allows). With a queue, a new consumer only sees new messages. That surprised me the most when I tried it.