بازگشت به کتابخانهکتابخانه17.2Case Study: طراحی Rate Limiter
طراحی سیستم نرم‌افزاریSYSTEM DESIGNاز صفر تا تسلط
v1.0.0
01مبانی و تصویر بزرگ
02Scalability و ظرفیت
03لایه داده
04Cache، Queue و جریان
05معماری نرم‌افزار
06قابلیت اطمینان و عملیات
07متد طراحی
08Case Study های واقعی
09سیستم‌های توزیع‌شده عمیق
10مهندسی تولید: داده، امنیت و کارایی
11تمرین پیشرفته و کیس‌استادی‌های مکمل
12زیر کاپوت دیتابیس و معماری داده
13وب بلادرنگ و پروتکل‌های مدرن
14سیستم‌های توزیع‌شده پیشرفته
15SaaS ،SRE ،امنیت و شبکه پیشرفته
16طراحی سیستم در عصر AI
17Case Study های تکمیلی
LESSON 17.2فصل ۱۷Case Study های تکمیلی

Case Study: طراحی Rate Limiter

  • ~۱۲ دقیقه
  • ۳ پرسش
  • متن را انتخاب کن تا هایلایت شود

مسئله: خودِ rate limiter را به‌عنوان یک «سرویس» طراحی کن — نه استفاده ازش (فصل ۴)، بلکه ساختنش: چند صد سرویس به آن وابسته‌اند و افت آن یعنی افت همه. مسئله ظاهراً کوچک، ولی پر از مصالحه است.

۱-۲) نیازمندی و تخمین

  • FR: قوانین منعطف (per-user ،per-IP ،per-API ،per-tenant با سقف‌های متفاوت)، پاسخ allow/deny در چند میلی‌ثانیه، و هدرهای Retry-After/مانده.
  • NFR: تأخیر در مسیر حیاتی <5ms ،overhead نزدیک صفر، خودِ limiter SPOF نباشد، و در پیک (موج ورود) زیر فشار نمیرد.
  • تخمین: اگر پلتفرم 500K RPS دارد، limiter باید همان را با p99 میلی‌ثانیه‌ای تحمل کند — شمارشگرها در Redis با INCR+EXPIRE یا sliding log در حافظه.

۳) طراحی — کجا و چطور

DIAGRAMدو محل قرارگیری
Client
Edge/LB — لایه ۷
API Gateway — قوانین
سرویس‌ها — قوانین محلی
  • سه محل: لبه (رحمتی‌ترین: ترافیک بد زود دور می‌شود)، Gateway مرکزی (سیاست یکدست)، و درون سرویس (قوانین خاص دامنه). سیستم بالغ هر سه را دارد — دفاع در عمق برای نرخ.
  • الگوریتم: Token Bucket برای عبور ریزه‌ایِ منصفانه با امکان burst کوتاه؛ Sliding Window برای دقت؛ Fixed Window ساده‌ترین ولی لبه‌ی پنجره عبور دو برابر می‌دهد (فصل ۴ را مرور کن).
  • شمارنده توزیع‌شده: هر گره محلی می‌شمارد و دوره‌ای با مرکز همگام می‌کند (eventual) — یا همه‌چیز در Redis مرکزی (دقیق‌تر، وابسته‌تر). مصالحه: دقت در برابر تأخیر/وابستگی.
  • Fail-open یا fail-close؟ اگر Redis limiter مرد: برای پرداخت fail-close (امنیت)، برای مشاهده صفحه عمومی fail-open با سقف اضطراری محلی — تصمیم بر اساس ریسک مسیر.

۴) عمق و گلوگاه

  • قانون‌ها را مثل کانفیگ زنده از دیتابیس/Config Service بخوان و کش کن — تغییر سقف برای مشتری نباید دیپلوی بخواهد.
  • 429 را با Retry-After و اطلاع «چه سقفی خورده‌ای» برگردان؛ تجربه توسعه‌دهنده مصرف‌کننده بخشی از طراحی است.
  • خود limiter هم باید load shed بفهمد: اگر فروش رویدادی آمد، اول قوانین کم‌اهمیت (آمار) را شل کن تا هسته زنده بماند (فصل ۱۵).

به زبان ساده

Rate Limiter خودش یک سرویس است: قوانین را زنده می‌خواند، شمارنده‌ها در حافظه می‌چرخند و باید از قبل بداند در خرابی خودش «باز» یا «بسته» شکستن یعنی چه.

مثال واقعی

مثل نگهبان باشگاه: سهمیه هر عضو را می‌داند؛ اگر دفترچه سهمیه‌اش (Redis) گم شود، برای سونا (پرداخت) محتاط است و برای سالن نمایش (محتوای عمومی) آزادتر.

دانش‌سنجی

آزمون درس

۳ Q
01
چرا Fixed Window در لبه پنجره می‌تواند عبور دوبرابری بدهد؟
02
برای مسیر پرداخت، limiter در خرابی Redis باید؟
03
مزیت قرارگیری limiter در لبه (edge