"User কে ধীর কাজের জন্য অপেক্ষা করানোর দরকার নেই: accept now, process later।"
স্টেজ ০৪ শেষে আমাদের system অনেক দিক থেকেই scalable: read distribute হচ্ছে, write shard হচ্ছে, content দুনিয়াজুড়ে পৌঁছে যাচ্ছে। কিন্তু একটা জিনিস এখনো বদলায়নি: প্রতিটা request এখনো synchronous। মানে user একটা কাজ করতে চাইলে, কাজটা পুরো শেষ না হওয়া পর্যন্ত তাকে বসে অপেক্ষা করতে হয়।
কিছু কাজ স্বভাবতই ধীর (video encode করা, email পাঠানো, report বানানো)। এগুলোর জন্য user কে আটকে রেখে অপেক্ষা করানোর কোনো মানে নেই। এই স্টেজে আমরা Message Queue দিয়ে “কাজ accept করা” আর “কাজ করা” কে আলাদা করে ফেলবো। User সাথে সাথে একটা acknowledgment পাবে, আর ধীর কাজটা পরে background এ হতে থাকবে। স্টেজ শেষে আপনি বুঝবেন কখন কোনো কাজ queue তে রাখা উচিত, আর তার বিনিময়ে কী cost দিতে হয়।
০১ এই স্টেজে যা শিখবো
| সেশন | শিরোনাম | এই সেশনের লক্ষ্য |
|---|---|---|
| সেশন ০৮ | Message Queue | Synchronous এর সীমা, asynchronous এ accept-now-process-later, producer/queue/consumer, ack + visibility timeout, at-least-once delivery আর idempotency, আর sustained overload এ backpressure। |
০২ স্টেজ শেষে যা যা করতে পারবেন
- Synchronous model এর সীমা চেনা: কখন user কে অপেক্ষা করানোটা একটা সমস্যা হয়ে দাঁড়ায়।
- Asynchronous processing বোঝা: সাথে সাথে acknowledge করে আসল কাজটা পরে করা।
- Producer / Queue / Consumer model আর decoupling এর সুবিধা বোঝা।
- Load leveling বোঝা: queue কীভাবে traffic spike absorb করে।
- Ack + visibility timeout দিয়ে crash এর পরও কাজ টিকিয়ে রাখা।
- Delivery guarantee আলাদা করা: at-most-once, at-least-once, exactly-once।
- Idempotency দিয়ে duplicate processing নিরাপদ করা।
- Backpressure, autoscaling, priority, shedding দিয়ে sustained overload সামলানো।
০৩ এর পর যা আসছে...
এই স্টেজে আমরা একটা single system এর ভেতরেই কাজ decouple করলাম। পরের স্টেজে আমরা পুরো monolith টাকেই ভাঙবো: Microservices কখন ও কেন দরকার, service-to-service communication, API Gateway, আর service discovery।