‫مدیریت نرخ درخواست در ASP.NET Core: پیکربندی‌هایی که زیر بار ترافیکی شکست می‌خورند

options.AddFixedWindowLimiter("orders", limiter =>
{
    limiter.PermitLimit = 1_000;
    limiter.Window = TimeSpan.FromMinutes(1);
    limiter.QueueLimit = 0;
});

[ پنجره ۱ (دقیقه اول) ]                   [ پنجره ۲ (دقیقه دوم) ]
|-----------------------||||||||| | |||||||||-----------------------|
                      ثانیه ۵۸ تا ۶۰   ثانیه ۰ تا ۲
                      (۱۰۰۰ درخواست)  (۱۰۰۰ درخواست)
                      
>>> نتیجه در مرز پنجره: ۲۰۰۰ درخواست در ۴ ثانیه (۵۰۰ درخواست بر ثانیه واقعی!)

var orders = await dbContext.Orders
    .AsNoTracking()
    .Where(x => x.CustomerId == customerId)
    .OrderByDescending(x => x.CreatedAt)
    .Take(100)
    .ToListAsync(cancellationToken);

• اشباع Connection Pool: تعداد کانکشن‌های فعال دیتابیس در چند میلی‌ثانیه به حداکثر مجاز (مثلاً سقف ۱۲۸ پیش‌فرض SqlClient) می‌رسد و درخواست‌های بعدی در صف انتظار کانکشن بلاک می‌شوند (Connection Timeout).
• فشار حافظه و CPU: بار سنگین تخصیص حافظه (Materialization) و سریال‌سازی هم‌زمان ۱۰۰ شیء به‌ازای هر درخواست، حافظه موقت Gen 0/Gen 1 را اشباع کرده و باعث راه‌اندازی فرآیند Garbage Collection فشرده می‌شود.
• رشد تاخیر زنجیره‌ای (Tail Latency): با درگیر شدن تردها، زمان اتمام درخواست‌ها طولانی‌تر شده و تقاضای نخ‌های پردازشی بالا می‌رود که نتیجه آن، آغاز پدیده ThreadPool Starvation در دات‌نت خواهد بود.

// جایگزینی Fixed Window با Sliding Window برای حذف جهش مرزی
options.AddSlidingWindowLimiter("orders-sliding", limiter =>
{
    limiter.PermitLimit = 1_000;
    limiter.Window = TimeSpan.FromMinutes(1);
    limiter.SegmentsPerWindow = 6; // تقسیم هر پنجره به ۶ سگمنت ۱۰ ثانیه‌ای
    limiter.QueueLimit = 0;
});

options.AddTokenBucketLimiter("orders-token", limiter =>
{
    limiter.TokenLimit = 50;              // حداکثر ظرفیت انفجاری مجاز در یک لحظه
    limiter.TokensPerPeriod = 16;          // اضافه شدن ۱۶ توکن در هر ثانیه
    limiter.ReplenishmentPeriod = TimeSpan.FromSeconds(1);
    limiter.QueueLimit = 0;
});

• یک درخواست به دلیل دریافت پاسخ از حافظه موقت (Cache)، در ۲۰ میلی‌ثانیه به پایان می‌رسد.
• درخواست دیگر به دلیل پاسخ‌دهی کند یک وب‌سرویس یا کوئری سنگین، ۲ ثانیه در سرور باز می‌ماند.

• انباشت درخواست‌های معلق (In-Flight Requests): چون زمان پایان هر درخواست از ۲۰ میلی‌ثانیه به ۲ ثانیه جهش کرده، تعداد درخواست‌های هم‌زمان در حافظه به‌سرعت ۱۰۰ برابر می‌شود.
• اشباع کانتینر DI و اشغال حافظه: سرویس‌های Scoped (مانند DbContext و ساختارهای ردیابی Entity Framework)، اشیای Activity مربوط به OpenTelemetry، بافرهای پاسخ و CancellationTokenها برای مدت طولانی‌تری زنده می‌مانند و تخصیص‌های Gen 1 و Gen 2 را به حداکثر می‌رسانند.
• اشباع Connection Pool: اتصالات باز دیتابیس آزاد نمی‌شوند و درخواست‌های جدید به دلیل اتمام سقف اتصالات منتظر مانده و خطا می‌دهند.

• Request Rate Limiter: تعیین می‌کند که «درخواست‌های جدید با چه فرکانس و سرعتی اجازه ورود دارند؟»
• Concurrency Limiter: تعیین می‌کند که «حداکثر چه تعداد از این درخواست‌ها می‌توانند به‌طور هم‌زمان در حافظه زنده و فعال باشند؟»

builder.Services.AddRateLimiter(options =>
{
    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;

    // تعریف یک محدودکننده زنجیره‌ای: کنترل فرکانس ورود + سقف پردازش هم‌زمان
    options.GlobalLimiter = PartitionedRateLimiter.CreateChained(
        // لایه ۱: هموارسازی ورود درخواست‌ها به ازای کاربر/IP
        PartitionedRateLimiter.Create<HttpContext, string>(context =>
        {
            var key = context.User.Identity?.Name 
                ?? context.Connection.RemoteIpAddress?.ToString() 
                ?? "anonymous";

            return RateLimitPartition.GetSlidingWindowLimiter(key, _ => new SlidingWindowLimiterOptions
            {
                PermitLimit = 120,
                Window = TimeSpan.FromMinutes(1),
                SegmentsPerWindow = 6,
                QueueLimit = 0
            });
        }),

        // لایه ۲: سقف صلب هم‌زمانی کل برنامه جهت ایمن‌سازی دیتابیس و تردپول
        PartitionedRateLimiter.Create<HttpContext, string>(_ =>
        {
            return RateLimitPartition.GetConcurrencyLimiter("global-concurrency", _ => new ConcurrencyLimiterOptions
            {
                PermitLimit = 50, // حداکثر ۵۰ درخواست باز در کل سیستم
                QueueLimit = 0
            });
        })
    );
});

options.AddConcurrencyLimiter("checkout", limiter =>
{
    limiter.PermitLimit = 100;
    limiter.QueueLimit = 1_000;
    limiter.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
});

• کلاینت‌ها، اپلیکیشن‌های موبایل و مرورگرها در آن سوی خط همچنان منتظر پاسخ هستند.
• زمان ماندن در صف مستقیماً به زمان کلی پاسخ‌دهی (End-to-End Latency) افزوده می‌شود.
• درخواست‌های معلق در صف، بخشی از سوکت‌های شبکه، ساختارهای داخلی وب‌سرور Kestrel و حافظه موقت را اشغال نگه می‌دارند.
• با آزاد شدن مجوزها، بار پردازشی انباشته‌شده محو نمی‌شود، بلکه به‌تازگی وارد خط لوله اجرا و درگیر کردن دیتابیس می‌شود.

• وب‌سرورهای بالادستی و Reverse Proxyها (نظیر Nginx یا YARP) درخواست را Timeout می‌کنند.
• اپلیکیشن‌های سمت کاربر به دلیل عدم دریافت پاسخ، درخواست را لغو کرده و مجدداً ارسال می‌کنند.
• در نهایت، زمانی که مجوز به درخواست اول در صف اعطا می‌شود، سرور منابع گران‌بهای دیتابیس و پردازشی را صرف اجرای درخواستی می‌کند که کلاینت پیش‌تر اتصال آن را قطع کرده است؛ در حالی که درخواست جدیدِ تکرارشده (Retry) نیز هم‌اکنون به انتهای صف اضافه شده است!

// استفاده از صف بسیار کوچک همراه با Fail-Fast برای حفظ بودجه تاخیر
options.AddConcurrencyLimiter("checkout-defensive", limiter =>
{
    limiter.PermitLimit = 50;  // سقف سخت‌گیرانه هم‌زمانی روی دیتابیس
    limiter.QueueLimit = 5;    // صف بسیار محدود صرفاً برای هموارسازی میلی‌ثانیه‌ای
    limiter.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
});

// بازگرداندن پاسخ شفاف با هدر Retry-After
options.OnRejected = async (context, token) =>
{
    context.HttpContext.Response.StatusCode = StatusCodes.Status429TooManyRequests;
    context.HttpContext.Response.Headers.RetryAfter = "5"; // پیشنهاد عقب‌نشینی ۵ ثانیه‌ای به کلاینت
    await context.HttpContext.Response.WriteAsync("سرویس موقتاً در حداکثر ظرفیت است. لطفاً چند لحظه بعد مجدداً تلاش کنید.", token);
};

options.GlobalLimiter = PartitionedRateLimiter.Create<HttpContext, string>(context =>
{
    var key = context.Connection.RemoteIpAddress?.ToString() ?? "unknown";

    return RateLimitPartition.GetFixedWindowLimiter(
        partitionKey: key,
        factory: _ => new FixedWindowRateLimiterOptions
        {
            PermitLimit = 100,
            Window = TimeSpan.FromMinutes(1),
            QueueLimit = 0
        });
});

• هزاران کاربر مستقل و معتبر، همگی دارای یک کلید پارتیشن یکسان (IP پروکسی) می‌شوند.
• سقف مجاز ۱۰۰ درخواست در دقیقه بین تمامی کاربران تقسیم می‌شود.
• با اولین فعالیت سنگین یک کاربر، کل کاربران پشت آن مسیر با خطای 429 Too Many Requests مسدود خواهند شد.

builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
    // افزودن شبکه‌ها یا لودبالانسرهای قابل اعتماد برای جلوگیری از جعل هدر
    options.KnownNetworks.Clear();
    options.KnownProxies.Clear();
});

// ...
// این میان‌افزار حتماً باید قبل از UseRateLimiter فراخوانی شود
app.UseForwardedHeaders();
app.UseRateLimiter();

options.GlobalLimiter = PartitionedRateLimiter.Create<HttpContext, string>(context =>
{
    // ۱. بررسی شناسه سازمانی برای سیستم‌های چندمستأجری
    var tenantId = context.User.FindFirst("tenant_id")?.Value;
    if (!string.IsNullOrEmpty(tenantId))
    {
        return RateLimitPartition.GetSlidingWindowLimiter($"tenant_{tenantId}", _ => new SlidingWindowLimiterOptions
        {
            PermitLimit = 500,
            Window = TimeSpan.FromMinutes(1),
            SegmentsPerWindow = 6,
            QueueLimit = 0
        });
    }

    // ۲. بررسی شناسه کاربر احرازهویت‌شده
    var userId = context.User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
    if (!string.IsNullOrEmpty(userId))
    {
        return RateLimitPartition.GetSlidingWindowLimiter($"user_{userId}", _ => new SlidingWindowLimiterOptions
        {
            PermitLimit = 120,
            Window = TimeSpan.FromMinutes(1),
            SegmentsPerWindow = 4,
            QueueLimit = 0
        });
    }

    // ۳. استفاده از IP امن برای کاربران ناشناس
    var ipAddress = context.Connection.RemoteIpAddress?.ToString() ?? "unknown_ip";
    return RateLimitPartition.GetFixedWindowLimiter($"ip_{ipAddress}", _ => new FixedWindowRateLimiterOptions
    {
        PermitLimit = 30,
        Window = TimeSpan.FromMinutes(1),
        QueueLimit = 0
    });
});

GET  /api/products/{id}
POST /api/reports/export
POST /api/orders
GET  /api/health

• اندپوینت products یک مدل کوچک و کش‌شده در Redis را با کمترین بار پردازشی برمی‌گرداند.
• اندپوینت reports/export یک کوئری تحلیلی سنگین را روی دیتابیس اجرا کرده، داده‌ها را مرتب‌سازی و به صورت یک فایل حجیم استریم می‌کند.
• اندپوینت orders تراکنش‌های مالی، رزرو موجودی و قفل‌گذاری روی جداول پایگاه داده را انجام می‌دهد.
• اندپوینت health صرفاً وضعیت زنده بودن پروسس را بررسی می‌کند و تقریباً هیچ منبعی مصرف نمی‌کند.

• قربانی شدن درخواست‌های سبک توسط درخواست‌های سنگین: اگر جهشی در درخواست‌های صدور گزارش رخ دهد، کل سهمیه سراسری به سرعت مصرف می‌شود. در نتیجه، درخواست‌های سبکِ مشاهده محصول (GET products) که سرور به‌راحتی توانایی پاسخ به هزاران مورد از آن‌ها را دارد، بی‌دلیل با خطای 429 Too Many Requests رد می‌شوند.
• اشباع و فلج شدن منابع زیرساختی: اگر سقف سراسری بر مبنای توان پاسخ‌دهی به درخواست‌های سبک تنظیم شده باشد (مثلاً ۱۰۰۰ درخواست در ثانیه)، ورود کسری از همین تعداد برای اندپوینت گزارش‌گیری سنگین، استخر اتصالات پایگاه داده (Connection Pool) و پردازنده را به طور کامل اشباع کرده و کل سرویس را زمین‌گیر می‌کند.
• از دسترس خارج شدن بررسی سلامت (Health Check): اگر اندپوینت health پشت همان سهمیه سراسری قرار گیرد، پر شدن سهمیه منجر به رد درخواست‌های Health Probe توسط لودبالانسر یا Kubernetes شده و پروسس سالم به اشتباه Restart می‌شود!

builder.Services.AddRateLimiter(options =>
{
    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;

    // ۱. سیاست درخواست‌های سبک و خواندنی: سهمیه بالا با مدیریت جهش
    options.AddTokenBucketLimiter("read-policy", limiter =>
    {
        limiter.TokenLimit = 200;
        limiter.TokensPerPeriod = 50;
        limiter.ReplenishmentPeriod = TimeSpan.FromSeconds(1);
        limiter.QueueLimit = 0;
    });

    // ۲. سیاست گزارش‌های سنگین: سقف سخت‌گیرانه هم‌زمانی روی منابع دیتابیس
    options.AddConcurrencyLimiter("expensive-report-policy", limiter =>
    {
        limiter.PermitLimit = 5; // حداکثر ۵ گزارش هم‌زمان در کل پروسس
        limiter.QueueLimit = 0;   // رد فوری درخواست‌های اضافه جهت حفظ دیتابیس
    });

    // ۳. سیاست تراکنش‌های ایجاد سفارش: تفکیک بر اساس شناسه کاربر
    options.AddPolicy("transactional-write-policy", context =>
    {
        var userId = context.User.Identity?.Name 
            ?? context.Connection.RemoteIpAddress?.ToString() 
            ?? "anonymous";

        return RateLimitPartition.GetSlidingWindowLimiter(userId, _ => new SlidingWindowLimiterOptions
        {
            PermitLimit = 10,
            Window = TimeSpan.FromMinutes(1),
            SegmentsPerWindow = 2,
            QueueLimit = 0
        });
    });
});

// ...

app.UseRateLimiter();

// اتصال صریح سیاست‌ها به اندپوینت‌ها
app.MapGet("/api/products/{id}", GetProduct)
   .RequireRateLimiting("read-policy");

app.MapPost("/api/reports/export", ExportReport)
   .RequireRateLimiting("expensive-report-policy");

app.MapPost("/api/orders", CreateOrder)
   .RequireRateLimiting("transactional-write-policy");

// معاف‌سازی اندپوینت‌های زیرساختی
app.MapGet("/api/health", () => Results.Ok(new { status = "Healthy" }))
   .DisableRateLimiting();

options.AddTokenBucketLimiter("dashboard-burst", limiter =>
{
    limiter.TokenLimit = 100;                 // سقف ظرفیت انفجاری
    limiter.TokensPerPeriod = 10;             // تولید ۱۰ توکن جدید
    limiter.ReplenishmentPeriod = TimeSpan.FromSeconds(1); // در هر ثانیه
    limiter.QueueLimit = 0;
});

• تیم محصول می‌گوید: «هر مشتری مجاز است تا سقف ۶۰۰ عملیات در دقیقه انجام دهد.»
• تیم فنی تنظیم می‌کند: یک Token Bucket با سقف ۶۰۰ توکن.

• سهمیه تجاری (Commercial Quota): مشتری چقدر حجم کاری خریداری کرده است؟
• ظرفیت لحظه‌ای زیرساخت (Instantaneous Infrastructure Capacity): سرور و پایگاه داده در همین ثانیه چه میزان فشار موازی را می‌توانند بدون افت کیفیت تحمل کنند؟

builder.Services.AddRateLimiter(options =>
{
    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;

    options.GlobalLimiter = PartitionedRateLimiter.CreateChained(
        // لایه ۱: اعمال سهمیه تجاری و مجاز شمردن جهش‌های کوتاه‌مدت کاربر
        PartitionedRateLimiter.Create<HttpContext, string>(context =>
        {
            var userId = context.User.Identity?.Name 
                ?? context.Connection.RemoteIpAddress?.ToString() 
                ?? "anonymous";

            return RateLimitPartition.GetTokenBucketLimiter(userId, _ => new TokenBucketRateLimiterOptions
            {
                TokenLimit = 60,               // حداکثر جهش مجاز به ازای کاربر
                TokensPerPeriod = 10,
                ReplenishmentPeriod = TimeSpan.FromSeconds(1),
                QueueLimit = 0
            });
        }),

        // لایه ۲: سقف فیزیکی هم‌زمانی روی دیتابیس و منابع سرور
        PartitionedRateLimiter.Create<HttpContext, string>(_ =>
        {
            return RateLimitPartition.GetConcurrencyLimiter("db-capacity-guard", _ => new ConcurrencyLimiterOptions
            {
                PermitLimit = 30,              // حداکثر ۳۰ اجرای واقعاً هم‌زمان روی منابع مشترک
                QueueLimit = 0
            });
        })
    );
});

options.AddFixedWindowLimiter("client-quota", limiter =>
{
    limiter.PermitLimit = 100;
    limiter.Window = TimeSpan.FromMinutes(1);
    limiter.QueueLimit = 0;
});

[ کلاینت / مهاجم ]
        │
        ▼ (ارسال درخواست‌ها با الگوی Round-Robin)
[ Load Balancer ]
   ├───► نود ۱ (مجاز: ۱۰۰)  ──► مصرف: ۱۰۰
   ├───► نود ۲ (مجاز: ۱۰۰)  ──► مصرف: ۱۰۰
   │     ...
   └───► نود ۱۰ (مجاز: ۱۰۰) ──► مصرف: ۱۰۰
────────────────────────────────────────────────────
>>> مجموع ترافیک مجاز واردشده به دیتابیس مشترک: ۱,۰۰۰ درخواست در دقیقه!

• محافظت از نمونه محلی (Local Instance Protection): جلوگیری از اشباع پردازنده، حافظه و نخ‌های کاری همان یک کانتینر.
• سهمیه‌بندی کلی و تجاری (Distributed Fleet-Wide Quota): اعمال دقیق سقف پلن خریداری‌شده توسط کاربر یا سازمان در کل سامانه.

• لایه گیت‌وی یا ریورس پروکسی: سهمیه تجاری کاربر (مثلاً ۱۰۰۰ درخواست در دقیقه) را با استفاده از کش توزیع‌شده کنترل می‌کند.
• لایه کانتینر ASP.NET Core: با یک ConcurrencyLimiter ساده و بدون نیاز به شبکه، سقف منابع فیزیکی همان پروسس را گارانتی می‌کند:

// نمونه پیکربندی درون پروسس برای محافظت مستقل هر نود
builder.Services.AddRateLimiter(options =>
{
    options.RejectionStatusCode = StatusCodes.Status429TooManyRequests;

    // کنترل سخت‌گیرانه هم‌زمانی روی همان نمونه محلی بدون وابستگی به شبکه
    options.AddConcurrencyLimiter("local-capacity-guard", limiter =>
    {
        limiter.PermitLimit = 40; // حداکثر ۴۰ عملیات هم‌زمان روی این نود
        limiter.QueueLimit = 0;   // رد آنی بدون ایجاد تأخیر در حافظه
    });
});

• انباشت حافظه موقت: هر درخواست معلق در صف، بافرهای HTTP، متادیتاها و سرویس‌های حوزه Scoped را در حافظه قفل نگه می‌دارد. در صورت تداوم فشار، صف‌های طولانی باعث رفتن آبجکت‌ها به Gen 2 و در نهایت فریز سیستم بر اثر Garbage collection یا خطای OutOfMemoryException می‌شوند.
• لغو درخواست توسط کلاینت و کار بیهوده سرور: اگر کلاینت بعد از ۲ ثانیه Timeout دهد اما درخواست ۵ ثانیه در صف منتظر مانده باشد، سرور پردازش سنگین دیتابیس را برای کلاینتی انجام می‌دهد که پیش‌تر ارتباط خود را قطع کرده است.
• تأخیر در بازیابی سیستم: پس از قطع ناگهانی ترافیک ورودی، اندازه‌گیری کنید چه مدت‌زمانی طول می‌کشد تا سرور صف‌های معوقه را تخلیه کرده و Latency را به سطح نرمال برگرداند.

• مدت زمان نگه‌داشت مجوزها (rate-limiting.request.lease.duration).
• زمان انتظار در صف (rate-limiting.request.time-in-queue).
• نسبت درخواست‌های ردشده به درخواست‌های صف‌بندی‌شده.

• وضعیت ThreadPool: شمارنده کارهای معلق (ThreadPool.PendingWorkItemCount) و مدت‌زمان رقابت بر سر قفل‌ها (Lock Contention).
• رفتار حافظه و GC: نرخ رشد فضای Heap و زمان مکث فرآیند GC حین اشباع صف‌ها.

• مدت زمان انتظار برای دریافت اتصال در Connection Pool دیتابیس و بررسی پدیده Pool Starvation.
• وضعیت مصرف استخر سوکت‌های خروجی HTTP.

• رهگیری صدک‌های تأخیر (p95، p99 و p99.9) صرفاً برای درخواست‌های موفق (HTTP 200)؛ تا مطمئن شوید حتی با رد شدن درصد بالایی از ترافیک اضافی، کیفیت سرویس‌دهی به درخواست‌های مجاز افت نکرده است.

• ایجاد گلوگاه در I/O دیتابیس: ایجاد تاخیر مصنوعی ۵۰۰ میلی‌ثانیه‌ای روی کوئری‌ها تا اطمینان حاصل شود Concurrency Limiter قبل از بروز خطای Timeout در Connection Pool وارد عمل شده و جریان را قطع می‌کند.
• توقف پاسخ وب‌سرویس‌های خارجی (Blackhole): قطع موقت پاسخ‌دهی سرویس‌های Downstream تا بررسی شود که آیا Rate Limiter مانع از تجمع درخواست‌ها پشت سوکت‌های معلق می‌شود یا خیر.

• Fixed Window می‌تواند سهمیه تجاری را دقیق اعمال کند، اما جهش‌های مخرب دوبرابری در مرز پنجره‌ها به همراه بیاورد.
• Sliding Window شمارنده ورود را هموار می‌کند، اما اگر پاسخ‌دهی به درخواست‌ها کند شود، در برابر رشد انفجاری هم‌زمانی (Concurrency) کاملاً ناتوان است.
• Token Bucket ورود جهشی ترافیک را مجاز می‌سازد، در حالی که ممکن است این جهش فراتر از ظرفیت هضم دیتابیس یا سوکت‌های خارجی باشد.
• Concurrency Limiter ظرفیت منابع حیاتی را مهار می‌کند، اما بدون پارتیشن‌بندی، با مسدود شدن توسط یک کاربر پرمصرف، عدالت را قربانی می‌کند.
• صف‌ها (Queues) می‌توانند رقابت‌های میلی‌ثانیه‌ای را تعدیل کنند، اما با کمی تغییر در شرایط، فشار لحظه‌ای را به یک بحران پایدار تأخیر (Tail-Latency Incident) تبدیل می‌سازند.
• پارتیشن‌بندی بر اساس IP کاربران ناشناس را تفکیک می‌کند، اما در غیاب پیکربندی Forwarded Headers، هزاران کاربر پشت یک پروکسی یا CDN را به اشتباه مسدود می‌سازد.
• محدودکننده سراسری (Global) حجم ترافیک کل را مهار می‌کند، در حالی که اندپوینت‌های سنگین تحلیلی با سرعتی بسیار بالاتر از خواندن‌های ساده کش‌شده، منابع مشترک را می‌بلعند.

• مدیریت محتاطانه صف‌ها: فعال‌سازی صف باید کاملاً آگاهانه و با ظرفیت‌های بسیار محدود باشد. رد سریع درخواست (Fail-Fast) از طریق ارسال آنی خطای 429، مکانیزمی حیاتی برای ایجاد فشار معکوس (Backpressure) است.
• پارتیشن‌بندی مبتنی بر مالکیت منبع: کلید پارتیشن باید بر اساس موجودیتی تعیین شود که انحصار آن منبع را در اختیار دارد (مانند TenantId برای دیتابیس مشترک سازمانی).
• تفکیک هزینه اندپوینت‌ها: با فرض برابری هزینه پردازش تمام درخواست‌های HTTP، سیستم را پیکربندی نکنید؛ برای عملیات سنگین سیاست‌های سخت‌گیرانه‌تری لحاظ کنید.
• تست در شرایط افت کارایی: تاب‌آوری Rate Limiter را با تزریق تاخیر عمدی در دیتابیس و شبیه‌سازی جهش‌های ترافیکی بسنجید، نه صرفاً در شرایط عادی و سلامت زیرساخت.