- کانال/مصاحبهکننده: Tech Dummies - Narendra Lakshmana Gowda
- مدت: 00:35:55
- ویدئو: https://www.youtube.com/watch?v=mhUQe4BKZXs
این سند خلاصهی یک مصاحبهی System Design است. دیدن ویدئو کامل توصیه میشود.
Teach Me: 5 Years Old | Beginner | Intermediate | Advanced | (reset auto redirect)
Learn Differently: Analogy | Storytelling | Cheatsheet | Mindmap | Flashcards | Practical Projects | Code Examples | Common Mistakes
Check Understanding: Generate Quiz | Interview Me | Refactor Challenge | Assessment Rubric | Next Steps
- صورت مسأله (یک خطی): طراحی یک rate limiter برای محافظت از API در برابر سوءاستفاده، پشتیبانی از quotaهای رایگان/پولی، و کارکرد درست در محیط توزیعشده.
- دامنهی اصلی: الگوریتمهای رایج rate limiting (token bucket، leaky bucket، fixed window counter، sliding logs، sliding-window counter) و رفتار آنها زیر ترافیک bursty و در multi-region. خارج از دامنه: قراردادهای دقیق API، SLA/متریکهای production، تنظیمات vendor‑specific.
- اولویتهای غیرعملکردی: اعمال سازگار، سربار latency کم، بهرهوری حافظه، عدالت در مصرف، تابآوری در برابر DDoS/brute force و کنترل هزینه.
- قیود و اعداد نمونه: حد کاربر مثلاً ۵ درخواست/دقیقه یا ۱۰ درخواست/دقیقه؛ quota آزمایشی توسعهدهنده؛ محدودیت همزمانی (sessionهای موازی)؛ scope براساس geo/IP.
- معماری سطحبالا (متنی):
- کلاینتها → Load Balancer
- سرویس Rate Limiter (نقطهی enforcement)
- ذخیرهساز مشترک برای counter/log (مثل Redis/Cassandra)
- سرورهای اپلیکیشن
- اختیاری: کش in‑memory محلی + sync پسزمینه به استور مشترک
- اختیاری: sticky sessions یا distributed locks برای کاهش race (با ملاحظهی معایب)
- معادلات کلیدی:
- تحمل burst در برابر هموارسازی (token bucket در برابر leaky bucket)
- دقت در برابر حافظه (sliding logs در برابر sliding‑window counter)
- سختگیری سراسری در برابر latency/دسترسپذیری (locks در برابر محدودیتِ کمی رها)
- سادگی در برابر سازگاری چندمنطقهای
- ریسکها/خرابیهای رایج:
- race بین regionها و over‑allow
- hot keyها که استور را تحت فشار میگذارند
- lockهای شدید و افزایش tail latency
- spike در مرز پنجرهها با fixed window (“double dip”)
- صفِ بیمهار در leaky bucket و فشار حافظه
- فلشکارت مرور ۵ دقیقهای:
- سؤال: چرا rate limit؟ پاسخ: حفاظت از UX، امنیت (brute force) و هزینه.
- سؤال: token bucket در یک خط؟ پاسخ: شارژ تدریجی token؛ هر درخواست یک token خرج میکند؛ burst تا ظرفیت سطل مجاز است.
- سؤال: leaky bucket در یک خط؟ پاسخ: صف + نرخ تخلیهی ثابت؛ burst را هموار میکند و در پرشدن صف drop میکند.
- سؤال: تلهی fixed window؟ پاسخ: امکان ~۲× درخواست نزدیک مرز پنجره.
- سؤال: مزیت sliding logs؟ پاسخ: دقت real‑time با ثبت timestamp درخواستها.
- سؤال: منفعت sliding‑window counter؟ پاسخ: دقت نزدیک به logs با حافظهی کمتر (تجمیع per‑bucket).
- سؤال: گزینههای سازگاری توزیعشده؟ پاسخ: sticky session، lock یا پذیرش خطای اندک.
- سؤال: سود کش محلی؟ پاسخ: کاهش round‑trip به قیمت drift کوچک.
- الگوی محصول:
rate-limit - ملاحظات سیستمی:
throttling, backpressure, high-availability, geo-replication, hot-key - فناوری/زیرساخت (ذکرشده):
redis, cassandra, load-balancer
- صورتبندی (بازنویسی): ساخت rate limiting برای مهار bot spikes و monetization با tierهای quota؛ پشتیبانی از محدودیتهای مبتنی بر کاربر، همزمانی، IP/مکان و سطح سرور.
- موارد استفاده:
- طرح رایگان توسعهدهنده (مثلاً ۱۰ req/min) در برابر enterprise
- جلوگیری از brute‑force در login/promo/booking
- مهار هزینه در سرویسهای auto‑scaling/pay‑as‑you‑go
- throttle بر پایهی location/IP در کمپینهای خاص
- خارج از دامنه: جزئیات auth، یکپارچهسازی billing، داشبورد analytics.
- APIها: در ویدئو تصریح نشده.
بر اساس ویدئو
- محدودسازی بر مبنای هویت: کاربر، سقف sessionهای همزمان، مبنا بر IP/لوکیشن، و scope سرویسی.
- استقرار توزیعشده با state مشترک → بروز race؛ sticky session و lock گزینهاند با معایب.
- کش محلی + sync غیرهمزمان برای کارایی بهتر با پذیرش اندکی drift.
فرضهای محافظهکارانه
- هدف سربار از زیر میلیثانیه تا چند میلیثانیه.
- quota قابل پیکربندی به تفکیک tenant/endpoint؛ در رد کردن 429 برگردانده میشود.
- رخدادهای observability روی allow/deny برای audit.
در ویدئو بیان نشده — صرفنظر میشود.
- ورود: کلاینتها → Load Balancerهای منطقهای.
- اعمال سیاست: سرویس Rate Limiter بهصورت منطقهای check را انجام میدهد.
- State: datastore مشترک برای counter/log (نمونهها: Redis یا Cassandra).
- لایهی اپ: درخواستهای مجاز به اپ سرورها میروند.
- ابزارهای سازگاری اختیاری: sticky session (affinity کاربر به یک region/app) یا distributed lock روی کلیدهای مشترک.
- sticky session توازن و fault tolerance را کاهش میدهد.
- lockها به قیمت latency، رقابت را کاهش میدهند.
- مسیر کارایی اختیاری: کش محلی per‑Limiter برای کلیدهای اخیر + آشتیِ پسزمینه با استور (قبول over‑allow اندک).
- نقش: اجازهی burst تا ظرفیت bucket؛ tokenها با نرخ ثابت شارژ میشوند؛ هر درخواست یک token مصرف میکند.
- state بهازای کلید: زمان آخرین refill، تعداد tokenهای موجود.
- رفتار: اگر token ≥ 1 → allow و کم کردن؛ وگرنه reject.
- نگرانی توزیعشده: بهروزرسانی همزمان یک کلید میتواند در استور مشترک race ایجاد کند.
- نقش: هموارسازی burst با صف FIFO و نرخ تخلیهی ثابت؛ در پرشدن صف، drop.
- تنظیمپذیری: ظرفیت صف (تحمل burst) و نرخ تخلیه (سقف throughput).
- ریسک: صفهای طولانی زیر spikeها موجب افزایش latency یا فشار حافظه میشود.
- نقش: شمارش درخواستها در بازههای ثابت (مثل هر دقیقه)؛ تا آستانه اجازه، سپس رد.
- اشکال: انفجار در مرز پنجرهها (double dip) و بیعدالتی مقطعی.
- نقش: نگهداری timestamp هر درخواست؛ هنگام تصمیمگیری، شمارش رخدادهای داخل بازهی T.
- مزیت: دقت real‑time.
- عیب: مصرف حافظهی بالا (تعداد زیاد timestamp).
- نقش: کاهش مصرف حافظه با تجمیع شمارندهها در bucketهای کوچک (مثلاً ثانیهای) داخل پنجرهی متحرک.
- رفتار: جمعِ bucketهای داخل T؛ اگر ≥ حد → drop.
- منفعت: دقت نزدیک به sliding logs با تعداد ورودی بسیار کمتر.
Ask AI: Sliding‑Window Counter
- مسأله: کاربرِ واحد از regionهای مختلف → بهروزرسانیهای race روی استور مشترک → over‑allow.
- گزینهها:
- sticky session (affinity کاربر به region/app). عیب: کاهش توازن/تابآوری.
- distributed lock روی هر کلید هنگام read/update. عیب: افزایش latency و contention.
- پذیرش اندکی خطا؛ enforcement کمی relaxed برای کارایی.
- کش محلی + آشتی غیرهمزمان با DB مشترک.
Ask AI: Distributed Enforcement
| موضوع | گزینه A | گزینه B | گرایش ویدئو | دلیل (از ویدئو) |
|---|---|---|---|---|
| هموارسازی burst | Token Bucket | Leaky Bucket | هر دو | Token اجازهی burst کوتاه؛ Leaky هموارسازی سختگیرانه. |
| پنجرهبندی | Fixed Window | Sliding (logs/counter) | Sliding | اجتناب از spikeهای مرزی و عدالت بهتر. |
| سازگاری | Locks | Relaxed limits | ترکیبی | lockها latency میافزایند؛ اندکی drift قابلقبول است. |
| affinity | Sticky Sessions | Any‑region | ترکیبی | affinity از race کم میکند ولی توازن/Failover را میکاهد. |
- سازگاری: سختگیری سراسری در multi‑region دشوار است؛ آشتیِ نهایی یا affinity/lockها بحث شدهاند.
- بودجهی latency: lock و تماس cross‑region latency میافزاید؛ کش محلی round‑trip را کم میکند.
- backpressure: leaky bucket پردازش را یکنواخت میکند؛ fixed window میتواند spike ایجاد کند.
- تخفیف فشار: با خالیشدن bucketها یا پرشدن صف → رهاسازی بار (429) برای حفاظت از سرویسهای هسته.
Ask AI: قابلیت اطمینان و کارایی
- جلوگیری از سوءاستفاده: مهار brute‑force (login، promo، booking).
- PII/Encryption: در ویدئو مطرح نشده.
- Metrics/Logs/Tracing: مطرح نشده. (در عمل: شمارش allow/deny، latency، و کلیدهای داغ.)
در ویدئو نیامده.
در ویدئو نیامده.
- انتخاب الگوریتم بر اساس نسبت burstiness ↔ هموارسازی.
- fixed window ساده ولی در مرزها ناعادلانه؛ برای دقت بهتر sliding ترجیح دارد.
- sliding‑window counter پیشفرض خوبی است: دقت کافی با مصرف حافظهی کم.
- enforcement توزیعشده پیچیده است؛ یا drift اندک را بپذیرید یا هزینهی lock/affinity را پرداخت کنید.
- کش محلی + sync غیرهمزمان latency را کم میکند ولی نیازمند بودجهی خطا است.
- محدودیتهای IP/لوکیشن و همزمانی متممِ quotaهای مبتنی بر کاربرند.
- Token Bucket: سطلِ شارژشونده؛ مصرف token برای عبور.
- Leaky Bucket: صف FIFO با تخلیهی ثابت.
- Fixed Window: شمارنده با بازههای زمانی ثابت.
- Sliding Logs: ثبت timestamp برای شمارش real‑time.
- Sliding‑Window Counter: تجمیع per‑bucket در پنجرهی متحرک.
- Sticky Sessions: نگهداشتن کاربر روی یک instance/region.
- Hot Key: کلیدی با فعالیت نامتناسب که contention میسازد.
- lock و sticky session بهعنوان گزینه مطرح شدهاند.
- fixed window به سادگی معرفی شده؛ در ۲۰۲۵ معمولاً sliding‑window counter ترجیح دارد.
- کش محلی + sync غیرهمزمان برای کاهش latency پیشنهاد شده؛ با بودجهی خطای معقول.
- ویدئو: https://www.youtube.com/watch?v=mhUQe4BKZXs
- کانال: Tech Dummies - Narendra Lakshmana Gowda
- توضیح: این سند خلاصهای از ویدئوی پیوندی است.
من Ali Sol، توسعهدهندهی PHP هستم. بیشتر بدانید:
- وبسایت: https://alisol.ir
- لینکدین: https://www.linkedin.com/in/alisolphp