A Rate Limiter That Knows Who's Calling

Suresh Thotakura — Sat, 29 Aug 2026 19:47:21 +0000

ASP.NET Core's rate limiter partitions however you key it. Key it on the caller, and one client's burst stops being every other client's problem.

I built a small lab to get that wiring right end to end.

Four stages:

Authenticate. A custom header scheme validates the client and issues a client_id claim. Nothing downstream can partition per client until this exists.
Partition. The policy reads that claim and keys the partition by client id plus HTTP verb. A client's read budget and write budget are separate buckets, and so are two different clients'.
Limit. Fixed window: 10 requests per 10 seconds, queue limit 0. No waiting in line, you either get a permit or you don't.
Enforce. Request 11 in the window gets HTTP 429.

The client's profile decides which partition it lands in:

Standard: limited on every verb.
Premium: reads skip the limiter, writes still get 10 per 10 seconds.
Unlimited: no limiter at all.

The part worth remembering is the ordering.
UseRateLimiter() has to run after UseAuthentication() and UseAuthorization(). Register it earlier and the policy executes before the client_id claim exists, so there is nothing to partition on. In this implementation that throws rather than quietly limiting on nothing, which is the failure mode you want: loud, not silent.

Three calls do the wiring: AddRateLimiter() to register the policy, UseRateLimiter() to put it in the pipeline, RequireRateLimiting() to attach it to an endpoint group.

Code, including the in-memory client fixtures and the Todo endpoints it protects: https://github.com/sthotakura/rate-limiter-lab

Sealed Isn't a Restriction, It's a Promise

Suresh Thotakura — Fri, 28 Aug 2026 18:53:06 +0000

Leaving a class open to inheritance is a design decision, not a default you can ignore.

The core idea

An unsealed class is a promise: every virtual member can be overridden without breaking what the class guarantees. Most classes never meant to make that promise. They're just unsealed by default, because that's what class gives you unless you say otherwise.

Common mistake: treating sealed as "I don't want to think about subclassing" rather than "this type's invariants would break if someone could."

One override breaks the promise

Here's the promise, a BankAccount that refuses to go negative:

public class BankAccount
{
    public decimal Balance { get; protected set; }

    public virtual void Withdraw(decimal amount)
    {
        if (amount > Balance)
            throw new InvalidOperationException();
        Balance -= amount;
    }
}

And here's the override that breaks it:

public class RiskyAccount : BankAccount
{
    public override void Withdraw(decimal amount)
    {
        Balance -= amount; // no check
    }
}

Nothing here is exotic. It compiles cleanly, and RiskyAccount is a
perfectly legal BankAccount as far as the type system is concerned. Open
one with a balance of 100 and withdraw 500:

BankAccount account = new RiskyAccount(100m);
account.Withdraw(500m);
Console.WriteLine($"Balance: {account.Balance:F2}");

Real dotnet run output:

Balance: -400.00

The check on the left never ran. virtual was an open invitation, and
RiskyAccount took it.

Sealing turns a silent bug into a compile error

Without sealed, the code above compiles and produces a wrong answer at
runtime; nothing points you at the problem until it's already in
production. With sealed, the same mistake becomes something the compiler
catches before the code ever runs:

public sealed class BankAccount
{
    public decimal Balance { get; protected set; }

    public void Withdraw(decimal amount)
    {
        if (amount > Balance) throw new InvalidOperationException();
        Balance -= amount;
    }
}

public class RiskyAccount : BankAccount { }

// error CS0509: 'RiskyAccount': cannot derive
// from sealed type 'BankAccount'

Sealing also makes virtual on Withdraw pointless, and the compiler
enforces that too:

public sealed class BankAccount
{
    public virtual void Withdraw(decimal amount) { /* ... */ }
}

// error CS0549: 'BankAccount.Withdraw(decimal)' is a new virtual
// member in sealed type 'BankAccount'

Both of those are real compiler errors, not paraphrased, verified against
a live build.

The takeaway