কেস স্টাডি: URL শর্টনার ডিজাইন করা

১ · রিকোয়ারমেন্ট

যেকোনো কেস স্টাডির প্রথম ধাপ (L01-এর ফাংশনাল/নন-ফাংশনাল পার্থক্য মনে করুন) — সিস্টেমটি কী করবে এবং কতটা ভালোভাবে করবে তা স্পষ্ট করা।

২ · ক্যাপাসিটি এস্টিমেশন (L02-এর পদ্ধতি)

L02-এ শেখা QPS হিসাবের পদ্ধতি এখানে সরাসরি প্রয়োগ করি। মাসে ১ সেকেন্ড = ৩০ × ৮৬,৪০০ = ২৫,৯২,০০০ সেকেন্ড ধরে —

৩ · শর্ট কোড জেনারেশন — গভীর বিশ্লেষণ

দুটি প্রধান পদ্ধতি আছে। অপশন A — হ্যাশ করে ট্রাংকেট: URL-এর MD5/SHA হ্যাশ নিয়ে প্রথম কয়েক অক্ষর নেওয়া — সহজ, কিন্তু দুটি ভিন্ন URL একই ট্রাংকেটেড কোড পেতে পারে (কোলিশন), তাই প্রতিবার একটি existence-check লাগবে (এবং কোলিশন হলে regenerate করতে হবে)। অপশন B — অটো-ইনক্রিমেন্টিং কাউন্টার: প্রতিটি নতুন URL একটি নতুন, সবসময়-বাড়তে-থাকা সংখ্যা পায় (1, 2, 3, ...), যা base62Base62 Encoding০-৯, a-z, A-Z — মোট ৬২টি চিহ্ন ব্যবহার করে একটি সংখ্যাকে ছোট স্ট্রিং-এ রূপান্তর — ঠিক যেমন base10 (দশমিক) বা base16 (হেক্স), শুধু ৬২টি প্রতীক দিয়ে।-এ এনকোড করা হয়। কাউন্টার-ভিত্তিক পদ্ধতিতে কোনো কোলিশন সম্ভবই না — প্রতিটি সংখ্যা ইউনিক, তাই এর এনকোডিংও ইউনিক। এই কোর্স কাউন্টার-ভিত্তিক পদ্ধতিকেই বেছে নেবে, কারণ এটি existence-check ছাড়াই নিশ্চিত ইউনিকনেস দেয়।

CHARS = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"  # ৬২টি চিহ্ন
BASE = len(CHARS)

def encode_base62(num):
    if num == 0:
        return CHARS[0]
    digits = []
    while num > 0:
        num, rem = divmod(num, BASE)
        digits.append(CHARS[rem])
    return "".join(reversed(digits))

def decode_base62(code):
    num = 0
    for ch in code:
        num = num * BASE + CHARS.index(ch)
    return num

# --- রাউন্ড-ট্রিপ টেস্ট: কয়েকটি auto-increment ID এনকোড করে আবার ডিকোড করে মেলানো ---
test_ids = [0, 1, 61, 62, 12345, 999_999_999, 3_521_614_606_207]
for i in test_ids:
    code = encode_base62(i)
    back = decode_base62(code)
    status = "OK" if back == i else "MISMATCH"
    print(f"id={i:>15,} -> code='{code}' -> decoded={back:>15,}  [{status}]")

# --- ৭-অক্ষরের base62 কোডের সম্ভাব্য মোট সংখ্যা ---
capacity_7char = 62 ** 7
print(f"\n৭-অক্ষরের base62 কোডের সম্ভাব্য সংখ্যা: {capacity_7char:,}")

# --- ক্যাপাসিটি এস্টিমেশন (L02 পদ্ধতি) ---
urls_per_month = 100_000_000
seconds_per_month = 30 * 86_400
avg_write_qps = urls_per_month / seconds_per_month
read_write_ratio = 100
avg_read_qps = avg_write_qps * read_write_ratio
print(f"গড় write QPS: {avg_write_qps:.1f}")
print(f"গড় read QPS ({read_write_ratio}:1 রেশিওতে): {avg_read_qps:.1f}")

৪ · হাই-লেভেল আর্কিটেকচার

রিকোয়েস্টের পথ এই কোর্সের চেনা বিল্ডিং ব্লকগুলো দিয়েই তৈরি — প্রতিটি বক্স একটি নির্দিষ্ট আগের পাঠের প্রয়োগ।

৫ · গভীর বিশ্লেষণ — রিডাইরেক্ট পাথ ও ক্যাশিং

যেহেতু রিড:রাইট ~১০০:১, রিডাইরেক্ট পাথের পারফরম্যান্সই সিস্টেমের সাফল্য ঠিক করে দেয়। L19-এর cache-aside প্যাটার্ন এখানে হুবহু প্রযোজ্য — একটি রিডাইরেক্ট রিকোয়েস্ট এলে প্রথমে ক্যাশ চেক হয় (hit হলে সরাসরি রিডাইরেক্ট, কোনো DB কল ছাড়াই); মিস হলে DB থেকে পড়ে ক্যাশে বসিয়ে দেওয়া হয়। যেহেতু কিছু URL ("hot" লিংক, যেমন ভাইরাল পোস্ট) বাকিদের চেয়ে বহুগুণ বেশি ক্লিক পায়, একটি ছোট ক্যাশও বেশিরভাগ ট্রাফিক সার্ভ করে ফেলতে পারে (Pareto-এর মতো একটি প্যাটার্ন — অল্প কিছু কী বেশিরভাগ ট্রাফিক বহন করে)।

লেখার পাশে, শর্ট কোড জেনারেশনের জন্য একটি কেন্দ্রীয় কাউন্টার সার্ভিস দরকার — কারণ একাধিক স্টেটলেস অ্যাপ সার্ভার (L12) সমান্তরালে কাউন্টার বাড়াতে চাইলে ডুপ্লিকেট ID এড়াতে কো-অর্ডিনেশন লাগবে। বাস্তব সিস্টেমে এটি সাধারণত হয় একটি ডেডিকেটেড অটো-ইনক্রিমেন্ট ডেটাবেস সিকোয়েন্স, অথবা প্রতিটি সার্ভারকে ID-এর একটি আলাদা রেঞ্জ (যেমন সার্ভার ১ পায় 1-1000, সার্ভার ২ পায় 1001-2000) আগে থেকে বরাদ্দ করে দেওয়া — যা শার্ডিং-এর (L17) মতো একই "পার্টিশন করে দাও, কোঅর্ডিনেশন কমাও" নীতি অনুসরণ করে।

৬ · ট্রেড-অফ