طراحی URL Shortener
مطالعه موردی کامل: طراحی کوتاه‌کننده URL (مثل bit.ly) — از نیازمندی‌ها تا معماری نهایی با همه اجزا
کلاسیک‌ترین مصاحبه
«یک URL Shortener مثل bit.ly طراحی کنید» — کوچک به‌نظر می‌رسد اما همه مفاهیم دوره را لمس می‌کند!
مرحله ۱: نیازمندی‌ها
- عملکردی: کوتاه‌کردن URL، ریدایرکت، اختیاری: انقضا، آمار کلیک
- مقیاس: ۱۰۰M URL جدید/ماه، ۱۰B ریدایرکت/ماه (خواندن ۱۰۰:۱!)
- تأخیر: ریدایرکت < ۱۰۰ms
- دسترس‌پذیری: ۹۹.۹۹٪ (لینک‌ها نمرند!)
مرحله ۲: تخمین ظرفیت
نوشتن: 100M/ماه ≈ 40 QPS
خواندن: 10B/ماه ≈ 4,000 QPS (پیک ~۱۲K!)
ذخیره: 100M × 500 بایت = 50GB/ماه = 0.6TB/سال
۵ سال با ۳× replication ≈ 10TB — قابل مدیریت!مرحله ۳: طراحی API و مدل
POST /shorten (long_url) → {short_url}
GET /{code} → 301/302 Redirect
جدول: (short_code, long_url, created_at, expiry)مرحله ۴: قلب طراحی — تولید کد کوتاه
کد ۷ کاراکتری Base62 (a-z, A-Z, 0-9): 62⁷ ≈ ۳.۵ تریلیون ترکیب — کافی!
| روش | ایده | مشکل |
|---|---|---|
| هش (MD5 اول ۷) | hash(url) | تصادم! + قابل حدس |
| تصادفی | random ۷ کاراکتر | چک تصادم لازم |
| شمارنده + Base62 ✓ | ID=125 → "cb" | نیاز به ID توزیع‌شده! |
انتخاب: Snowflake ID (مبحث ۲۷!) + Base62 = یکتا، مرتب، بدون هماهنگی!
مرحله ۵: معماری کامل
کاربر → CDN/LB → سرویس Shorten
↓
ID Generator (Snowflake)
↓
DB (شارد بر ID) + کش
کاربر → LB → سرویس Redirect
↓
کش Redis (code→url) ← ۹۵٪ hit!
↓ miss
DB Replica → 302 Redirect- خواندن ۱۰۰:۱ → کش اجباری؛ Redis با LRU
- ریدایرکت: 301 (دائمی، کش مرورگر!) یا 302 (آمار کلیک!)
- شاردینگ: بر ID — نوشتن توزیع می‌شود
نکات عمیق‌تر (برای امتیاز!)
- Cache Stampede روی کد داغ؟ (مبحث ۱۱) — lock/coalescing
- لینک‌های محبوب → پیش‌گرم کش
- انقضا: TTL در DB + پاک‌سازی دوره‌ای
- امنیت: block URL مخرب (چک هنگام ثبت)
این یک مسئله، LB، کش، شاردینگ، Snowflake، Base62 و Cache-Aside را با هم نشان می‌دهد — در مصاحبه، هر جزء را با «چرا» بگویید!
جمع‌بندی
- خواندن ۱۰۰:۱ → کش قلب سیستم
- کد کوتاه: Snowflake + Base62
- شارد بر ID، Replica برای خواندن
- 301 برای کش مرورگر، 302 برای آمار
این مبحث بخشی از دوره آموزش کامل طراحی سیستم (System Design) است.