Notification Service: channel, preference ও delivery
Notification Service
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Channel-neutral notification intent সংরক্ষণ
- Preference, dedupe ও delivery state design
- Provider retry এবং unknown outcome সামলানো
সমস্যা দিয়ে শুরু
Order shipped হলে customer email, SMS এবং app notification চান, marketing SMS বন্ধ রেখেছেন। একটি worker crash করে একই SMS দুইবার পাঠাল। Requirements: transactional ও marketing category, preference, channel selection, retry, status এবং operator replay। Inbox message তৈরি, provider accepted এবং device delivery আলাদা state। Provider webhook সব channel-এ সমান reliable নয়, তাই delivery promise documented করতে হবে।
সহজ করে বুঝি
Notification service business event থেকে durable intent বানায়। Channel-specific delivery attempt queue-তে যায়। Stable event/recipient/channel key local duplicate intent ঠেকায়। Provider request outcome unknown হলে reconciliation বা provider-supported idempotency দরকার। User preference send-time বা event-time কোনটি হবে স্পষ্ট করুন। Unsubscribe এবং mandatory transactional notice-এর business/legal policy আলাদা হতে পারে; সব channel-এ blanket assumption দেবেন না।
পরিচিত একটি উপমা
একটি চিঠির dispatch register, courier booking এবং recipient receipt আলাদা খাতা। Register-এ নাম একবার আছে বলেই courier দুইবার যায়নি বলা যায় না। Recipient কোন ধরনের চিঠি চান সেটিও dispatch-এর আগে পরীক্ষা করতে হয়।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart LR E[Business event] --> I[(Notification intent)] I --> P[Preference and policy] P --> Q[Channel queues] Q --> W[Channel workers] W --> V[Email SMS push provider] V --> H[Verified delivery updates] H --> D[(Attempt history)]
Event থেকে unique intent লেখা হয়। Preference channel নির্ধারণ করে। পৃথক queue provider rate limit এবং failure isolation সহজ করে। Worker provider result attempt history-তে রাখে; delivery callback signature যাচাই করে status এগোয়। Marketing backlog-এর কারণে critical OTP আটকে না যায়—priority এবং dedicated budget দরকার। OTP payload log বা general inbox-এ রাখবেন না।
PHP ও Laravel-এ প্রয়োগ
Assumption: দিনে ২০ লাখ recipient notification, average ২৩ events/second; multi-channel attempts ও retry আরও বেশি। POST /notification-intents internal authorized, GET /me/notifications scoped। intents table-এ event_key, recipient_id, category unique scope; attempts-এ channel, provider_ref,status। নিচের Laravel fragment queued notification dispatch দেখায়; OrderShipped implements ShouldQueue এবং preference-aware channel logic আগে লিখতে হবে। Transaction boundary-এর পরে dispatch করুন।
use App\Notifications\OrderShipped;
use Illuminate\Support\Facades\DB;
DB::afterCommit(function () use ($user, $order) {
$user->notify(new OrderShipped($order->id));
});সুবিধা, সীমাবদ্ধতা ও trade-off
Async send user request দ্রুত করে, final delivery delay বাড়ায়। Channel isolation noisy provider-এর প্রভাব কমায় কিন্তু বেশি worker management লাগে। Local unique intent provider duplicate effect পুরোটা আটকায় না। Bulk campaign batch size ও rate budget carefully দিন। Provider switch delivery continuity বাড়াতে পারে, কিন্তু same notification দুই provider-এ চলে যাওয়ার race design করতে হবে।
সাধারণ ভুল
- Queued মানেই recipient delivered বলা।
- এক failed SMS বারবার unlimited retry করা।
- Unsubscribe preference cache stale রেখে marketing পাঠানো।
আরও একটু গভীরে
Retryable technical error এবং permanent invalid address আলাদা করুন। TTL পার হওয়া OTP পরে deliver করে লাভ নেই; queue expiration policy চাই। Dead-letter replay operation audit করুন এবং dedupe key preserved রাখুন। Template version ও locale intent-এ রাখলে replay reproducible হয়। Sensitive message-এর retention ছোট করুন; provider callback spoofing ঠেকাতে documented verification করুন।
মনে রাখুন
Notification reliable হয় durable intent, channel-specific bounded attempts এবং সঠিক preference/delivery semantics দিয়ে।
নিজে চেষ্টা করুন
একই order-shipped event তিনবার আসা এবং provider timeout-এর পরে delayed callback আসা scenario লিখুন। OTP, marketing এবং receipt queue-এর priority ও expiry নির্ধারণ করুন। Replay-তে duplicate কীভাবে সামলাবেন বলুন।
নিজের বোঝা যাচাই করুন
1. Queued মানে delivered?
না। Local acceptance, provider acceptance ও recipient delivery আলাদা state; UI ও metrics-এ আলাদা দেখান।
2. Unique intent কেন যথেষ্ট নয়?
Provider side effect সফল হয়ে response হারাতে পারে। Local dedupe সেই uncertain external outcome পুরোটা resolve করে না।
3. Preference কখন দেখব?
Product policy অনুযায়ী event-time বা send-time। Unsubscribe-sensitive channel-এ freshness deliberateভাবে নিশ্চিত করুন।
4. সব failure retry?
Permanent invalid address retry করে লাভ নেই। Transient failure bounded backoff এবং expiry দিয়ে সামলান।
5. Replay-তে key বদলাব?
একই logical intent হলে dedupe identity preserved রাখুন। Deliberate resend আলাদা audited operation হিসেবে model করুন।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।