চূড়ান্ত প্রকল্প — সম্পূর্ণ সিস্টেম ডিজাইন ইন্টারভিউ সিমুলেশন

১ · প্রকল্পের প্রেক্ষাপট

কল্পনা করুন একটি ইন্টারভিউয়ার আপনাকে বলছেন: "একটি নোটিফিকেশন সিস্টেম ডিজাইন করুন যা ইউজারদের লাইক, কমেন্ট ও নতুন ফলোয়ার সম্পর্কে প্রায়-রিয়েল-টাইমে জানায় — পুশ ও ইন-অ্যাপ দুই চ্যানেলেই।" ফাংশনাল রিকোয়ারমেন্ট সরল মনে হলেও, নন-ফাংশনাল দিকটা কঠিন — বিশাল স্কেল, কোনো নোটিফিকেশন হারানো যাবে না, এবং একজন ইউজারকে একই ইভেন্টের জন্য বারবার স্প্যাম করা যাবে না। নিচে আমরা এই সিস্টেমটি ধাপে ধাপে ডিজাইন করব, প্রতিটি সিদ্ধান্তে এই কোর্সের নির্দিষ্ট মডিউল ও লেসন উল্লেখ করে — ঠিক যেমন একটি বাস্তব ইন্টারভিউয়ে করা হয়।

২ · ধাপ ১ (M1, L01-02) — রিকোয়ারমেন্ট ও ক্যাপাসিটি অনুমান

L01-এর ফ্রেমওয়ার্ক অনুযায়ী ফাংশনাল ও নন-ফাংশনাল রিকোয়ারমেন্ট আলাদা করা হয়েছে উপরে। L02-এর পদ্ধতিতে ক্যাপাসিটি অনুমান করা যাক — ধরি প্রতিদিন ২০ কোটি (২০,০০,০০,০০০) ইভেন্ট (লাইক+কমেন্ট+ফলো একত্রে) তৈরি হয়, প্রতিটি ইভেন্ট গড়ে ১.৫ জন ইউজারকে নোটিফাই করে (যেমন একটি কমেন্টে একাধিক থ্রেড-পার্টিসিপেন্ট নোটিফাই হতে পারে)।

events_per_day = 200_000_000
notifications_per_event = 1.5
seconds_per_day = 24 * 60 * 60

total_notifications_per_day = events_per_day * notifications_per_event
avg_notification_qps = total_notifications_per_day / seconds_per_day

peak_factor = 3   # L01-এর পিক-ফ্যাক্টর ধারণা
peak_notification_qps = avg_notification_qps * peak_factor

print(f"মোট নোটিফিকেশন/দিন: {total_notifications_per_day:,.0f}")
print(f"গড় নোটিফিকেশন QPS: {avg_notification_qps:,.1f}")
print(f"পিক নোটিফিকেশন QPS (~{peak_factor}x): {peak_notification_qps:,.1f}")

৩ · ধাপ ২ (M2, L06/L08) — ক্লায়েন্ট API ও ডেলিভারি চ্যানেল

ইউজার তার নোটিফিকেশন লিস্ট আনতে একটি সাধারণ REST এন্ডপয়েন্ট (L06) ব্যবহার করে — GET /notifications। কিন্তু নতুন নোটিফিকেশন রিয়েল-টাইমে ইউজারকে জানাতে (যাতে বারবার পোল করতে না হয়) একটি WebSocketWebSocketক্লায়েন্ট-সার্ভারের মধ্যে একটি পার্সিস্টেন্ট, ফুল-ডুপ্লেক্স কানেকশন — সার্ভার থেকে ক্লায়েন্টে পুশ করার জন্য আদর্শ, L08 দেখুন। (L08) কানেকশন ব্যবহার করা হয় ইউজার অ্যাপ চালু থাকা অবস্থায় — অ্যাপ বন্ধ থাকলে অপারেটিং-সিস্টেম-লেভেল পুশ নোটিফিকেশন সার্ভিস (APNs/FCM) ব্যবহার হয়।

৪ · ধাপ ৩ (M3, L10-12) — লোড ব্যালেন্সিং ও স্টেটলেস ডেলিভারি সার্ভার

নোটিফিকেশন-ডেলিভারি সার্ভারগুলো সম্পূর্ণ স্টেটলেস (L12) রাখা হয় — কোন ইউজার কোন সার্ভারে কানেক্টেড তার তথ্য একটি শেয়ারড স্টোরে (Redis-জাতীয়) থাকে, সার্ভারে নয়। একটি লোড ব্যালেন্সার (L11) ইনকামিং রিকোয়েস্ট বিতরণ করে, এবং হরাইজন্টাল স্কেলিং (L10) দিয়ে ট্রাফিক বাড়লে নতুন সার্ভার যোগ করা যায় — কোনো সার্ভারের ক্যাপাসিটি সিলিং ছাড়াই।

৫ · ধাপ ৪ (M4, L14/L17) — স্টোরেজ ডিজাইন

নোটিফিকেশন রেকর্ড (append-heavy, "সাম্প্রতিক নোটিফিকেশন আনো" অ্যাক্সেস প্যাটার্ন) একটি NoSQL স্টোর-এ (L14) সংরক্ষিত হয়, user_id দিয়ে শার্ডেড (L17) — যাতে "এই ইউজারের নোটিফিকেশন" কোয়েরি সবসময় একটি একক শার্ডে সম্পন্ন হয়, ক্রস-শার্ড জয়েন ছাড়াই।

৬ · ধাপ ৫ (M5, L19) — আনরিড কাউন্ট ক্যাশিং

"আপনার কয়টি না-পড়া নোটিফিকেশন আছে" — এই প্রশ্নটি অ্যাপ খোলার সাথে সাথে প্রতিটি ইউজার বারবার জিজ্ঞেস করে, তাই এটি একটি ক্লাসিক উচ্চ-রিড, কম-রাইট প্যাটার্ন। আনরিড কাউন্ট প্রতিবার পুরো নোটিফিকেশন টেবিল স্ক্যান করে গোনার বদলে একটি ক্যাশে (L19-এর cache-aside প্যাটার্ন) সংরক্ষিত থাকে, প্রতিটি নতুন নোটিফিকেশনে ইনক্রিমেন্ট হয়।

৭ · ধাপ ৬ (M6, L22-23) — ইভেন্ট-ড্রিভেন জেনারেশন

যখন কেউ একটি পোস্ট লাইক করে, সেই সার্ভিসটি সরাসরি নোটিফিকেশন সার্ভিসকে কল করে না — বরং একটি "PostLiked" ইভেন্ট পাবলিশ করে একটি pub/sub সিস্টেমে (L22)। নোটিফিকেশন সার্ভিস সেই ইভেন্টের একজন সাবস্ক্রাইবার — এটি স্বাধীনভাবে ইভেন্ট শুনে নোটিফিকেশন তৈরি করে (L23-এর ইভেন্ট-ড্রিভেন আর্কিটেকচার)। এই ডিকাপলিং মানে লাইক-সার্ভিস নোটিফিকেশন-সার্ভিসের অস্তিত্ব সম্পর্কে কিছুই জানে না — ভবিষ্যতে নতুন সাবস্ক্রাইবার (যেমন অ্যানালিটিক্স) যোগ করা সহজ।

৮ · ধাপ ৭ (M7, L25-27) — আর্কিটেকচার প্যাটার্ন

নোটিফিকেশন একটি আলাদা, স্বাধীনভাবে-স্কেলযোগ্য মাইক্রোসার্ভিস (L25) — মূল অ্যাপ থেকে আলাদা ডিপ্লয় হয়, একটি API গেটওয়ের (L26) পেছনে বসে যা রাউটিং ও অথেন্টিকেশন হ্যান্ডল করে। এই সার্ভিস যখন এক্সটার্নাল পুশ-নোটিফিকেশন প্রোভাইডারকে (APNs/FCM) কল করে, একটি সার্কিট ব্রেকার (L27) সেই কলকে সুরক্ষা দেয় — প্রোভাইডার ধীর/ডাউন হলে ব্রেকার দ্রুত ফেইল করে, পুরো নোটিফিকেশন সার্ভিসকে আটকে না রেখে।

৯ · ধাপ ৮ (M9, L35/L38) — আইডেম্পোটেন্সি ও রেট লিমিটিং

দুটি নন-ফাংশনাল রিকোয়ারমেন্ট এখানে সরাসরি কোডে প্রয়োগ করা দরকার। প্রথমত — নেটওয়ার্ক রিট্রাই (L27) একই ইভেন্টের জন্য send_notification() দুইবার কল করতে পারে; একটি আইডেম্পোটেন্সি-কী (L38) এই ডুপ্লিকেট সেন্ড আটকায়। দ্বিতীয়ত — একটি অত্যন্ত সক্রিয় থ্রেড (যেমন একটি ভাইরাল পোস্টে শত শত কমেন্ট) একজন ইউজারকে স্প্যাম করতে পারে; একটি পার-ইউজার রেট লিমিট (L35) এটি আটকায়। নিচের কোড দুটোই একসাথে বাস্তবায়ন করে।

RATE_LIMIT_PER_WINDOW = 3   # প্রতি সিমুলেটেড উইন্ডোতে ইউজারপ্রতি সর্বোচ্চ ৩টি নোটিফিকেশন

processed_keys = {}          # idempotency_key -> ফলাফল (L38)
user_send_count = {}         # user_id -> এই উইন্ডোতে পাঠানো নোটিফিকেশন সংখ্যা (L35)

def send_notification(user_id, event_id, idempotency_key):
    # ধাপ ১ — আইডেম্পোটেন্সি চেক (L38): আগে প্রসেস হয়ে থাকলে পুনরায় না পাঠিয়ে ক্যাশড ফলাফল ফেরত দাও
    if idempotency_key in processed_keys:
        return "deduped", processed_keys[idempotency_key]

    # ধাপ ২ — রেট লিমিট চেক (L35): এই ইউজার এই উইন্ডোতে সীমা ছাড়িয়ে গেলে ব্লক করো
    count_so_far = user_send_count.get(user_id, 0)
    if count_so_far >= RATE_LIMIT_PER_WINDOW:
        return "rate_limited", None

    # ধাপ ৩ — প্রকৃত সেন্ড (শুধু এখানেই, একবারই ঘটে)
    user_send_count[user_id] = count_so_far + 1
    result = f"notification[{event_id}] sent to {user_id}"
    processed_keys[idempotency_key] = result
    return "accepted", result

# একটি সিমুলেটেড কল-সিকোয়েন্স — একটি রিপিটেড আইডেম্পোটেন্সি-কী + একটি রেট-লিমিট-ছাড়ানো বার্স্ট
calls = [
    ("u1", "like_1",    "key1"),
    ("u1", "like_1",    "key1"),   # <- একই কী পুনরায় (যেমন একটি রিট্রাই)
    ("u1", "comment_1", "key2"),
    ("u1", "follow_1",  "key3"),
    ("u1", "like_2",    "key4"),   # <- u1-এর জন্য ৪র্থ প্রচেষ্টা, সীমা ৩ ছাড়িয়ে যায়
    ("u1", "like_3",    "key5"),   # <- এখনও রেট-লিমিটেড
    ("u1", "like_4",    "key6"),   # <- এখনও রেট-লিমিটেড
    ("u2", "like_5",    "key7"),   # <- ভিন্ন ইউজার, তার নিজস্ব তাজা কাউন্টার
]

report = {"accepted": 0, "deduped": 0, "rate_limited": 0}

for user_id, event_id, idem_key in calls:
    status, result = send_notification(user_id, event_id, idem_key)
    report[status] += 1
    print(f"send_notification({user_id}, {event_id}, {idem_key}) -> {status} | {result}")

print("\n=== চূড়ান্ত রিপোর্ট ===")
print(f"accepted (গৃহীত)         : {report['accepted']}")
print(f"deduped (ডিডুপ্লিকেটেড)  : {report['deduped']}")
print(f"rate_limited (সীমা ছাড়ানো): {report['rate_limited']}")
print(f"মোট কল                    : {sum(report.values())}")

১০ · ধাপ ৯ (M10, L39/L41-42) — সিকিউরিটি ও অবজারভেবিলিটি

প্রতিটি নোটিফিকেশন-রিকোয়েস্টে ইউজারের আইডেন্টিটি টোকেন যাচাই করা হয় (L39-এর অথেন্টিকেশন), যাতে কেউ অন্য ইউজারের নোটিফিকেশন লিস্ট বা আনরিড-কাউন্ট দেখতে না পারে। ইভেন্ট থেকে ডেলিভারি পর্যন্ত পুরো পথ একটি একক ট্রেস-আইডি দিয়ে ট্র্যাক করা হয় (L41-এর ডিস্ট্রিবিউটেড ট্রেসিং) — "একটি নোটিফিকেশন পৌঁছাতে কেন দেরি হলো" ডিবাগ করতে অপরিহার্য। দলটি একটি SLO (L42) সেট করে — যেমন "৯৯.৯% নোটিফিকেশন ৫ সেকেন্ডের মধ্যে ডেলিভার হবে" — এবং এই SLO-ই মনিটরিং ড্যাশবোর্ড ও অ্যালার্টের ভিত্তি।