فصل 20 از 24 درس 1 از 1

Caching و Rate Limiting

Caching و Rate Limiting

بخشی از آموزش جامع ASP.NET Core Web API با .NET 10

محتوای درس Caching و Rate Limiting

.NET 10 | Output Cache، Memory Cache و کنترل نرخ

Caching فشار روی Dependencyها و زمان پاسخ را کاهش می‌دهد، اما تنها برای داده‌ای مناسب است که سیاست Freshness روشن داشته باشد. Rate Limiting نیز مصرف منابع را بر اساس Client یا Route کنترل می‌کند.

این فصل با تمرکز بر قراردادهای قابل اتکا، مرزبندی مسئولیت‌ها و رفتار قابل پیش‌بینی در محیط واقعی تنظیم شده است. مثال‌ها بر پایه ASP.NET Core و .NET 10 نوشته شده‌اند.

1. چارچوب موضوع و مفاهیم اصلی

Caching فشار روی Dependencyها و زمان پاسخ را کاهش می‌دهد، اما تنها برای داده‌ای مناسب است که سیاست Freshness روشن داشته باشد. Rate Limiting نیز مصرف منابع را بر اساس Client یا Route کنترل می‌کند.

واژگان و قراردادهای این بخش باید در سراسر پروژه یکدست بمانند؛ تفاوت میان لایه HTTP، منطق برنامه و زیرساخت زمانی روشن می‌ماند که مسئولیت هر جزء به‌صورت صریح تعریف شود.

مفهومکارکرد
Cache Keyشناسه داده Cache
TTLعمر Cache
Invalidationحذف داده قدیمی
Output CacheCache پاسخ HTTP
Rate Limitسقف Request
Partitionتفکیک سهم Client

2. ساختار پیشنهادی در پروژه

داده عمومی Read-heavy می‌تواند Output Cache داشته باشد. داده حساس User-specific باید Key و Policy مناسب داشته باشد. Rate Limiter پیش از عملیات پرهزینه اعمال می‌شود.

builder.Services.AddOutputCache();

var app = builder.Build();
app.UseOutputCache();

app.MapGet("/api/catalog", GetCatalog)
   .CacheOutput(policy => policy.Expire(TimeSpan.FromMinutes(2)));

3. سناریوی اجرایی

برای Endpoint جست‌وجوی عمومی، Rate Limit بر اساس IP یا Client Id تعریف می‌شود. Endpoint Login محدودیت سخت‌گیرانه‌تری دارد تا Brute Force و مصرف بی‌رویه کاهش یابد.

در این سناریو، قرارداد ورودی و خروجی، مسیر شکست و رفتار قابل مشاهده سرویس باید پیش از جزئیات پیاده‌سازی مشخص شود. این رویکرد باعث می‌شود تغییرات بعدی بدون وابستگی پنهان و با امکان تست دقیق انجام شوند.

builder.Services.AddRateLimiter(options =>
{
    options.AddFixedWindowLimiter("login", limiter =>
    {
        limiter.PermitLimit = 5;
        limiter.Window = TimeSpan.FromMinutes(1);
        limiter.QueueLimit = 0;
    });
});

4. اصول طراحی و نگهداری

پیاده‌سازی قابل نگهداری تنها به درست کار کردن در مسیر موفق محدود نیست. مرزهای مسئولیت، قابلیت مشاهده، امنیت، رفتار در خطا و امکان توسعه تدریجی باید هم‌زمان بررسی شوند.

  • Cache برای داده حساس بدون Scope مناسب استفاده نشود.
  • Invalidation هم‌زمان با Writeهای مهم طراحی شود.
  • Rate Limit بر اساس Identity معتبر در صورت امکان Partition شود.
  • 429 و Headerهای مرتبط قابل مشاهده باشند.

5. خطاهای رایج و کنترل آن‌ها

بخش مهمی از کیفیت یک API در نحوه جلوگیری از خطاهای تکرارشونده مشخص می‌شود. موارد زیر باید در بازبینی کد و تست‌های قبل از انتشار کنترل شوند.

  • Cache کردن Response کاربر A و ارائه به کاربر B.
  • TTL بسیار طولانی بدون Invalidation.
  • Rate Limit سراسری که یک Client همه ظرفیت را مصرف کند.
  • Cache به‌عنوان راه‌حل Query بد بدون اصلاح منبع.

6. چک‌لیست نهایی فصل

  • Policy Cache برای هر Endpoint روشن است.
  • Cache Key همه ابعاد لازم را پوشش می‌دهد.
  • Rate Limit برای Endpointهای حساس فعال است.
  • پاسخ 429 و رفتار Client تست شده است.

7. جمع‌بندی

مفاهیم این فصل زمانی کامل محسوب می‌شوند که هم مسیر موفق و هم مسیر خطا قابل پیش‌بینی، قابل تست و قابل مشاهده باشند. طراحی نهایی باید با Contract API، امنیت و نیازهای نگهداری پروژه هماهنگ بماند.