Notification সিস্টেম ডিজাইন: push, SMS ও email
Notification সহজ মনে হয়, যতক্ষণ না লক্ষ লক্ষ push, SMS ও email পাঠান। নির্ভরযোগ্য ও ভদ্র pipeline ডিজাইন করি।
লক্ষ্য: অন্য service-রা একটি notification সিস্টেমকে ডেকে user-কে push, SMS, email বা in-app message পাঠায়, নির্ভরযোগ্যভাবে এবং spam ছাড়া।
Requirement
- একাধিক channel ও template (অনেক ভাষায়)।
- User preference ও নীরব সময় মানা।
- Retry সহ নির্ভরযোগ্য delivery, ডুপ্লিকেট ছাড়া।
- Spike সামলানো (sale শুরু হলে লক্ষ মানুষকে জানানো)।
- Delivery status ট্র্যাক।
Architecture
- API / event গ্রহণ: service-রা "event Y নিয়ে user X-কে জানাও" পাঠায়, সাথে template ID ও data।
- Notification service: যাচাই করে, user-এর preference ও যোগাযোগ তথ্য দেখে, rate limit পরীক্ষা করে, template render করে এবং channel ঠিক করে।
- Queue: প্রতিটি channel-এর (push, SMS, email) আলাদা queue, যাতে ধীর SMS provider push আটকাতে না পারে।
- প্রতি channel-এ worker: message নেয় ও provider-কে ডাকে (push-এর জন্য APNs ও FCM, SMS gateway, email সেবা)।
- Status ট্র্যাকিং: sent, delivered, failed, opened রেকর্ড।
Queue কেন
এরা spike শোষণ করে, channel-দের মধ্যে ব্যর্থতা আলাদা রাখে এবং exponential backoff সহ retry দেয়। বারবার ব্যর্থ হলে message পরীক্ষার জন্য dead-letter queue-তে যায়।
ডুপ্লিকেট এড়ানো
Provider ও queue at-least-once। প্রতিটি notification-কে অনন্য dedup key দিন (যেমন user + event + template) এবং সময়সীমার মধ্যে পুনরাবৃত্তি বাদ দিন। Worker idempotent রাখুন।
অগ্রাধিকার
জরুরি traffic (এককালীন পাসওয়ার্ড, নিরাপত্তা সতর্কতা) বাল্ক marketing থেকে আলাদা রাখুন, নিজস্ব queue ও ক্ষমতা সহ, যাতে campaign কখনো login কোড দেরি না করায়।
Preference ও নিয়মকানুন
- User-কে channel ও বিভাগ অনুযায়ী বন্ধ করতে দিন। Transactional ও marketing message-এর নিয়ম আলাদা।
- Unsubscribe লিংক ও স্থানীয় আইন মানুন।
- Opt-in/out-এর রেকর্ড রাখুন।
Rate limit ও batching
একজন user ঘণ্টায় কতগুলো notification পাবে তার সীমা দিন, আর কম গুরুত্বেরগুলো batch বা digest করুন ("৫টি নতুন comment")। Provider-এর rate limit-ও মানুন।
যেসব ব্যর্থতার জন্য তৈরি থাকবেন
অবৈধ push token (সরিয়ে দিন), bounce হওয়া email (পাঠানো বন্ধ করুন), provider বন্ধ (দ্বিতীয় provider-এ failover), এবং data-হীন template (পাঠানোর আগে যাচাই)।
Observability
Queue-র গভীরতা, event থেকে delivery পর্যন্ত latency, provider error হার এবং channel অনুযায়ী delivery সাফল্য ট্র্যাক করুন।
মূল কথা: channel-ভিত্তিক queue দিয়ে আলাদা করুন, পাঠানো idempotent রাখুন, জরুরি ও বাল্ক আলাদা করুন, preference মানুন, আর provider failover ভাবুন।
System Design সিরিজ, পর্ব ৩ (case study): 8 নম্বর (মোট 16)। আগের লেখা: Mobile wallet-এর জন্য payment সিস্টেম ডিজাইন.
