একটি কোম্পানি-ব্যাপী notification service কীভাবে ডিজাইন করবেন?

Question

IT Interview Practice · Accepted Answer

একটি service তৈরি করুন যা প্রতিটি team একটি **notification type + recipient** দিয়ে কল করে, এবং service-কে channel, template, ইউজার preference, ও priority নির্ধারণ করতে দিন। মূল ডিজাইন চাল হলো **priority lane** — একটি OTP ২০ লক্ষ-ইউজারের marketing blast-এর পেছনে অপেক্ষা করতে পারে না।

## আর্কিটেকচার

```text
Services ─▶ Notify API ─▶ [validate + enrich] ─▶ Kafka topics
                                                 ├─ otp/txn  (high lane)
                                                 └─ marketing (bulk lane)
                                                      │
                            ┌──── Dispatcher (per lane) ────┐
                            │ prefs check ─▶ template render │
                            └────┬──────┬──────┬────────────┘
                              Push   Email   SMS   In-App
                                 (provider adapters + rate limit)
```

## কম্পোনেন্ট ও ফ্লো

- **Notify API** একটি typed request নেয়: `{type: "otp", user, data}`। Caller কখনও channel বাছে না বা copy লেখে না — service সেটি নিয়ন্ত্রণ করে, তাই একটি template পরিবর্তন একবারে ship হয়।
- **Type → policy**: প্রতিটি **type** একটি policy-তে map করে। *OTP* high-priority, SMS+Push, marketing opt-out উপেক্ষা করে, ৬০সে-এ expire হয়। *Transactional* (receipt, password reset) high, channel pref মানে। *Marketing* low, bulk lane, কঠোরভাবে opt-out ও quiet hours মানে।
- **Priority lane** হলো আলাদা consumer group সহ আলাদা Kafka topic। high lane প্রায়-খালি থাকে এবং মিলিসেকেন্ডে drain হয়; bulk lane OTP latency স্পর্শ না করেই মিনিটের জন্য জমতে পারে। এটিই একক সবচেয়ে গুরুত্বপূর্ণ সিদ্ধান্ত।
- **Preference service** প্রতি recipient-এ চেক করা হয়: opt out করেছে? quiet hours? per-channel toggle? frequency cap? একটি preference লঙ্ঘন করা marketing এখানে drop হয়।
- **Template engine** একটি versioned template + variable থেকে localized content render করে, যাতে copy ও কোড decoupled থাকে।
- **Channel adapter** FCM/APNs, SendGrid, Twilio-কে একটি interface-এর পেছনে মোড়ায়, প্রতিটির নিজস্ব rate limiter, retry ও DLQ সহ (যেকোনো bulk sender-এর মতো একই fan-out শৃঙ্খলা)।

## ইন্টারভিউ দৃষ্টিভঙ্গি

ইন্টারভিউয়াররা যাচাই করেন আপনি **concern** আলাদা করেন কিনা: অনেক প্রার্থী একটি monolith বানায় যা সরাসরি email পাঠায়, তারপর আবিষ্কার করে marketing বন্যা OTP-কে বিলম্বিত করে। *priority lane*, *preference enforcement*, এবং *idempotency key* (যাতে একটি retried request double-notify না করে) নাম ধরে বলা হলো senior signal। ভালো উত্তর channel যোগ করে; দারুণ উত্তর ব্যাখ্যা করে কেন OTP ও marketing কখনও একটি queue ভাগ করবে না এবং একটি **fallback chain** (Push fail → SMS) কীভাবে কাজ করে।

## ট্রেড-অফ ও ব্যর্থতা

- **একটি service বনাম per-team**: কেন্দ্রীকরণ ধারাবাহিক pref, throttling ও audit দেয়, কিন্তু একটি critical dependency হয়ে ওঠে — এটি অবশ্যই HA হতে হবে, নইলে একটি login OTP outage পুরো কোম্পানিকে আটকে দেয়।
- **Real-time বনাম খরচ**: SMS ব্যয়বহুল ও ধীর; Push/In-App পছন্দ করুন এবং high-value type-এর জন্যই কেবল SMS-এ fall back করুন।
- **Failure**: একটি provider outage fallback chain trigger করে, hard fail নয়। **Dedup key** একটি queue redelivery-কে একটি OTP দুবার পাঠানো থেকে বিরত রাখে। প্রতি-type delivery SLO ট্র্যাক করুন — একটি বিলম্বিত marketing email ঠিক আছে, একটি বিলম্বিত OTP একটি incident।

আর্কিটেকচার

কম্পোনেন্ট ও ফ্লো

ইন্টারভিউ দৃষ্টিভঙ্গি

ট্রেড-অফ ও ব্যর্থতা

সম্পর্কিত প্রশ্ন