URL Shortener Trade-off Audit

နားလည်ထားရမယ့် အချက်

ဒီ course တစ်လျှောက်လုံးရဲ့ system-design decision တိုင်းဟာ မေးခွန်းသုံးခုတည်းအထိ ကျဉ်းသွားပါတယ်၊ ပြီးတော့ decision တစ်ခုကို နောက်ကျမှ review လုပ်တယ်ဆိုတာ original ရွေးချယ်မှုကို ယုံကြည်နေမယ့်အစား ဒီမေးခွန်းတွေကို ရှင်းရှင်းလင်းလင်း ဖြေရမှာပါ။ ပထမမေးခွန်း — ဒီရွေးချယ်မှုက ဘာကုန်ကျစေလဲ (complexity, latency, durability, operational burden, ဒါမှမဟုတ် ငွေကြေး)? ဒုတိယ — ဘာရရှိစေလဲ (များသောအားဖြင့် simplicity, shipping မြန်နှုန်း, ဒါမှမဟုတ် scale နည်းတဲ့အချိန်မှာ ကုန်ကျစရိတ် သက်သာမှု)? တတိယ — အများဆုံး ကျော်သွားတတ်တဲ့ မေးခွန်း — အဖြေက ဘယ်နေရာမှာ ပြောင်းပြန်လှန်သွားလဲ — ဘယ် request volume, data size, ဒါမှမဟုတ် uptime requirement မှာ စျေးသက်သာတဲ့ ရွေးချယ်မှုက တကယ်တမ်း မှားလာလဲ? in-memory dict ဟာ free ဖြစ်ပြီး မြန်ပါတယ်၊ process restart တစ်ခု ဖန်တီးထားတဲ့ short link တိုင်းကို ဖျက်ပစ်တဲ့အထိပေါ့။ auto-incrementing counter ဟာ server များစွာက code တွေ collision မဖြစ်ဘဲ ထုတ်ပေးဖို့ လိုအပ်မချင်း trivial ပါ။ cache မရှိတာဟာ viral link တစ်ခုက read traffic ရဲ့ 40% ကို မယူချင်းအထိ ရိုးရှင်းဆုံးပါ။ single server ဟာ product တစ်ခုလုံးကို ဖျက်ချနိုင်တဲ့ single point of failure ဖြစ်မလာချင်းအထိ ဈေးအသက်သာဆုံးပါ။ discipline ဆိုတာက ဘက်တစ်ဘက်ကိုပဲ ရွေးတာမဟုတ်ဘဲ crossover point ကို သတ်မှတ်ပေးဖို့ ဖြစ်ပါတယ်။

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

ဒီ course ထဲက URL shortener project ကိုပဲ အသုံးပြုထားတဲ့ Tutorial Platform ရဲ့ 'share this lesson' short-link feature ကို review လုပ်နေတယ်လို့ ယူဆပါ။ original engineer က in-memory dict, auto-incrementing counter, cache မရှိခြင်း, single server ကို ရွေးခဲ့ပါတယ် — feature launch တုန်းက တစ်ရက်ကို link ရာနှုန်းလောက်ပဲရှိတဲ့အချိန်မှာ ဒါဟာ ကျိုးကြောင်းညီညွတ်ပါတယ်။ reviewer အနေနဲ့ သင့်ရဲ့ အလုပ်က ရွေးချယ်မှုတွေကို 'မှား' လို့ ကြေညာဖို့ မဟုတ်ဘဲ Tutorial Platform ရဲ့ လက်ရှိ traffic က trade-off ပြောင်းလဲသွားတဲ့ scale ကို ကျော်သွားပြီလားဆိုတာ စစ်ဆေးဖို့၊ ဘယ်ရွေးချယ်မှုတွေက ဆက်ခိုင်မာနေသေးလဲ ဘယ်တွေကို production မှာ feature ကျိုးပေါက်မသွားခင် ပြန်ကြည့်ဖို့လိုနေပြီလဲ ဆုံးဖြတ်ပေးဖို့ ဖြစ်ပါတယ်။

• design decision တိုင်းမှာ ပွင့်ပွင့်လင်းလင်း ဖော်ပြရမယ့် အစိတ်အပိုင်း ၃ ခုရှိတယ် — ဘာကုန်ကျလဲ၊ ဘာရရှိလဲ၊ ဘယ် scale မှာ trade-off ပြောင်းလွှသွားလဲ။
• စျေးသက်သာတဲ့ ရွေးချယ်မှု (in-memory storage, no cache, single server) ဟာ scale နည်းတဲ့အချိန်မှာ မှားယွင်းတာမဟုတ်ဘူး — crossover point ကို ကျော်မှသာ မှားလာတာပါ။
• past decision တစ်ခုကို audit လုပ်တာက original choice ဟာ 'good practice' လား မဟုတ်လား ပြန်စဉ်းစားနေတာမဟုတ်ဘဲ လက်ရှိ scale ကို crossover point နဲ့ တိုက်စစ်တာပါ။

အတူတူ စမ်းရေးကြည့်မယ်

# Scenario 1: storage - in-memory dict vs a real database
# Tutorial Platform's URL shortener started with:
#   short_to_long = {}   # short_code -> original_url, held in process memory
# It handles 200 short links/day, all created and read within the same
# process lifetime. No restarts have happened in production yet.

# Scenario 2: short code generation - auto-incrementing counter vs hash-based codes
# counter = 0
# def make_short_code():
#     global counter
#     counter += 1
#     return base62_encode(counter)
# Runs on a single web server. Traffic has grown to 50,000 new links/day
# and the team is discussing adding a second server for redundancy.

# Scenario 3: caching - no cache vs a read cache for hot short codes
# def resolve(short_code):
#     return short_to_long[short_code]   # every redirect hits the dict/DB directly
# One influencer's shared link now accounts for ~40% of all redirect
# traffic in a single afternoon.

# Scenario 4: single server vs load balancing/replication
# The entire service - API, storage, code generation - runs on one EC2
# instance. It has handled all traffic since launch with 99.9% uptime,
# but the last outage (a routine OS patch reboot) took the whole
# shortener down for 6 minutes, breaking every shared link site-wide.

ဆုံးဖြတ်ချက်တစ်ခုစီအတွက် အဖြေတစ်ခုတည်းမရှိပါဘူး — audit က correct ဖြစ်ဖို့ဆိုရင် conclusion တစ်ခုစီမှာ concrete crossover condition ကို သတ်မှတ်ပေးရပါမယ် — in-memory dict ဟာ restart မဖြစ်သေးမချင်း (သို့) multi-server မလိုအပ်မချင်းပဲ ကောင်းတယ်၊ counter ဟာ server များစွာကနေ code generate လုပ်ရန် မလိုအပ်မချင်းပဲ ကောင်းတယ်၊ no cache ဟာ link တစ်ခုက read traffic ကို လွှမ်းမိုးမလာမချင်းပဲ ကောင်းတယ်၊ single server ဟာ outage ရဲ့ ကုန်ကျစရိတ်က redundancy ထည့်တဲ့ ကုန်ကျစရိတ်ထက် မကျော်မချင်းပဲ ကောင်းတယ် — ပြီးတော့ Tutorial Platform ရဲ့ လက်ရှိ scenario တွေ (50,000 links/day, traffic ရဲ့ 40% ယူထားတဲ့ viral link, production outage) က crossover တိုင်းကို ကျော်သွားပြီးသားဖြစ်တာကို ပြသနေပါတယ်။

Wikipedia — Non-functional requirement — System Design