Queue বনাম Pub/Sub: কাজ ভাগ ও event broadcast
Queues vs. Publish/Subscribe
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Work queue ও broadcast event আলাদা করুন
- প্রতিটি subscriber-এর নিজস্ব backlog রাখুন
- Laravel listener-এর delivery boundary বুঝুন
সমস্যা দিয়ে শুরু
Order paid হলে email, warehouse ও analytics সবাই খবর চায়। Team তিন worker-কে একটি queue শুনতে দিল। কিন্তু প্রতিটি message কেবল একজন worker পেল; analytics কিছু order জানল, warehouse অন্য কিছু। কাজ ভাগ করা আর খবরের একাধিক copy দেওয়া গুলিয়ে গেছে।
সহজ করে বুঝি
Work queue-তে competing consumers একই কাজ ভাগ করে; একটি delivery সাধারণত এক consumer process করে, retry-তে অন্যজন পেতে পারে। Pub/Sub-এ event একাধিক subscription-এ যায়। প্রত্যেক subscriber-এর durable queue থাকলে slow analytics email delivery আটকে রাখে না। Ephemeral subscription disconnected থাকলে ঘটনা হারাতে পারে।
পরিচিত একটি উপমা
একটি রান্নাঘরের order slip যে কোনো একজন রাঁধুনি নিলে কাজ ভাগ হয়। কিন্তু নতুন policy জানাতে cashier, kitchen ও delivery desk প্রত্যেককে আলাদা copy দিতে হয়। একটি slip টেনে নেওয়ার বাক্স দিয়ে announcement broadcast করা যায় না।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart LR O[Order Paid] --> E[Event Router] E --> Q1[Mail Queue] E --> Q2[Warehouse Queue] E --> Q3[Analytics Queue] Q1 --> M[Mail Worker] Q2 --> W[Warehouse Worker] Q3 --> A[Analytics Worker]
Publisher একটি fact পাঠায়। Router তিন subscription-এ স্বাধীন delivery তৈরি করে। প্রতিটি queue-এর worker সংখ্যা আলাদা বাড়ানো যায়। Analytics queue জমলেও mail queue চলতে পারে। Router-এ publish সফল হওয়া মানে তিনটি business effect সম্পূর্ণ হয়েছে নয়।
PHP ও Laravel-এ প্রয়োগ
Laravel event ও queued listener mapping-এর fragment। OrderPaid event এবং তিনটি listener আগে আছে; প্রত্যেক listener ShouldQueue implement করে নিজস্ব queue নির্ধারণ করবে। In-process event dispatch durable broker fan-out-এর সমান নয়; commit ও publish gap-এর জন্য outbox লাগতে পারে।
use App\Events\OrderPaid;
use App\Listeners\SendReceipt;
use App\Listeners\ReserveShipment;
use App\Listeners\RecordSale;
use Illuminate\Support\Facades\Event;
Event::listen(OrderPaid::class, SendReceipt::class);
Event::listen(OrderPaid::class, ReserveShipment::class);
Event::listen(OrderPaid::class, RecordSale::class);
// Each listener implements ShouldQueue and selects its own queue.
// Do not register the same listeners again through auto-discovery.
// The event contains stable order and event identifiers, not secrets.
event(new OrderPaid($order->id, $eventId));এটি PHP 8.3+ ও Laravel 12-এর শিক্ষামূলক fragment; সম্পূর্ণ application নয়। সংশ্লিষ্ট route-এ authentication ও resource authorization প্রয়োগ করতে হবে। নিচের অনুশীলনে failure ইচ্ছা করে তৈরি করুন; শুধু সফল response দেখে correctness ধরে নেবেন না।
সুবিধা, সীমাবদ্ধতা ও trade-off
Independent subscribers publisher-এর coupling কমায় এবং নতুন analytics consumer যোগ সহজ করে। কিন্তু event schema, delivery retry ও প্রতিটি subscription-এর monitoring দরকার। খুব ছোট app-এ synchronous function call সহজ; side effect-এর latency বা reliability প্রয়োজন হলেই queue যোগ করুন।
সাধারণ ভুল
- এক queue-তে তিন ধরনের worker দিয়ে তিন copy আশা করা।
- Subscriber down থাকলে ephemeral channel history রাখে ভাবা।
- এক listener failure-এর খবর কোথায় যাবে না ভাবা।
আরও একটু গভীরে
Broadcast transport এবং durable event bus-এর semantics আলাদা। Laravel broadcasting browser client update-এর জন্য হতে পারে; financial integration event-এর storage guarantee আলাদা যাচাই করুন। Subscription retention ও replay policy ownership-এর অংশ।
Warehouse worker বন্ধ রেখে order event দিন। Email যায় এবং warehouse backlog বাড়ে দেখুন। Worker ফিরে backlog process হবে। এরপর duplicate event দিন; warehouse reservation যেন unique event identity দিয়ে repeat না হয়। Routing-এর পাশাপাশি business idempotency এখনও দরকার।
মনে রাখুন
- Queue কাজ ভাগ করে, subscription খবর ভাগ করে।
- Slow consumer-এর backlog আলাদা রাখুন।
- Publish success business completion নয়।
নিজে চেষ্টা করুন
Order cancelled event-এর জন্য inventory, payment ও email subscriber আঁকুন। কোন consumer temporary failure-এ retry করবে লিখুন।
নিজের বোঝা যাচাই করুন
1. এক queue যথেষ্ট?
এক ধরনের কাজ বহু worker ভাগ করলে যথেষ্ট; প্রত্যেক subsystem সব event চাইলে আলাদা subscription দরকার।
2. Subscriber বন্ধ থাকলে?
Durable queue backlog রাখতে পারে; ephemeral delivery-তে সেই guarantee নাও থাকে।
3. Publish success কী?
Transport contract অনুযায়ী গ্রহণ; subscriber side effect শেষ হয়েছে এমন নয়।
4. Laravel event durable?
In-process dispatch নিজে durable log নয়; queued listener ও publishing gap আলাদা design করতে হয়।
5. Duplicate কেন ভাবব?
Ack loss বা publisher retry-তে একই event আবার আসতে পারে, তাই subscriber deduplication লাগে।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।