Innovabit.DotNet.Interceptors.RateLimiting.Abstractions 2.0.115

Innovabit.DotNet.Interceptors.RateLimiting.Abstractions

Per-method rate limiting for Innovabit.DotNet.Interceptors via a [RateLimit] attribute. This is the provider-agnostic base: it ships the interceptor, the attribute and the IRateLimiterStore abstraction. Pick a store to keep the allowances:

• Innovabit.DotNet.Interceptors.RateLimiting.Memory — in this process.
• Innovabit.DotNet.Interceptors.RateLimiting.Redis — shared across every instance.

Usage

services
    .AddInterceptors()
    .AddInMemoryRateLimiter();        // or .AddRedisRateLimiter()

services.AddScopedWithInterception<IQuoteService, QuoteService>();

public class QuoteService : IQuoteService
{
    // 100 calls a minute, per tenant.
    [RateLimit(PermitLimit = 100, WindowSeconds = 60, PartitionBy = "tenantId")]
    public Task<Quote> GetAsync(string tenantId, string symbol, CancellationToken cancellationToken) { ... }
}

A call that does not fit throws RateLimitExceededException without reaching the method, so nothing was attempted and it is always safe to retry. The exception carries RetryAfter, ready for an HTTP Retry-After header or a broker's delay.

[RateLimit]

Partition by something that identifies the caller, not the request. A value with unbounded cardinality — a search term, a request id — would create an allowance per call: it would limit nothing and grow the store forever.

Partition values are rendered with the invariant culture, so the same tenant cannot end up in two allowances depending on the culture of the thread that served the call.

Misconfiguration fails loudly

A PartitionBy that matches no parameter throws, naming the parameters that do exist, instead of quietly falling back to a global allowance — that mistake only shows up once the quota is already doing the wrong thing. A PermitLimit or WindowSeconds of zero or less throws for the same reason.

Ordering

The interceptor runs at InterceptorOrders.RateLimit (60), near the outside:

• A throttled caller spends nothing — no authorization lookup, no validation, no cache read.
• It is inside auditing (50), so the refused attempt is still recorded.
• It is outside notifications (300), so being throttled does not page anyone.

Using [RateLimit] the other way round — to throttle calls your service makes to a metered dependency — wants the opposite position, near the circuit breaker. Move it per registration:

services.AddInterceptors()
    .AddInMemoryRateLimiter()
    .SetOrder<RateLimitInterceptor>(InterceptorOrders.CircuitBreaker - 10);

Writing a store

public sealed class MyStore : IRateLimiterStore
{
    public ValueTask<RateLimitDecision> TryAcquireAsync(
        string partitionKey, RateLimitPolicy policy, CancellationToken cancellationToken = default) { ... }
}

services.AddInterceptors().AddRateLimiterStore<MyStore>();

Document what your store does when it cannot answer. The bundled ones let the call through: a rate limiter exists to protect you from too much traffic, and taking the service down because the limiter is unavailable trades a degraded service for no service at all.

License

MIT