DEV Community: Sukhpinder Singh

7.8 MB of Keys I Allocated Just to Throw Away

Sukhpinder Singh — Tue, 04 Aug 2026 08:09:59 +0000

A profiler trace put me on a code path I'd never once suspected: a request handler that reads a blob of space-separated tokens and sums a weight for each one it recognizes. The logic is boring and correct. What caught my eye was 7.8 MB of string allocations sitting in the hot loop of something that only ever reads those tokens. I wasn't keeping any of them. I was allocating a key, doing one dictionary lookup, and dropping it on the floor.

The keys were substrings. Every token I sliced out of the blob became its own little string object just so I could hand it to Dictionary.TryGetValue. So I measured what that habit actually costs, and what the span-based alternate lookup buys back.

The setup

The input is one string of 200,000 space-separated tokens, about 1.5 MB. Roughly 70% of them are real keys that live in a 5,000-entry Dictionary<string, long>; the rest are misses. The job walks the blob, pulls out each token, looks it up, and adds the weight. Timings are the median of 9 rounds after a warmup, allocations come from GC.GetAllocatedBytesForCurrentThread, .NET 10, Release build, small Linux container. Not a lab. I care about the ratios.

Here's the version I'd been writing forever:

int start = 0;
for (int i = 0; i <= input.Length; i++)
{
    if (i == input.Length || input[i] == ' ')
    {
        string token = input.Substring(start, i - start);   // allocates
        if (table.TryGetValue(token, out long w)) sum += w;
        start = i + 1;
    }
}

Substring is the tell. It reads like exactly what I mean, which is why it never gets flagged in review. And for a handful of tokens it's genuinely fine. Here's the bill for 200,000:

[A: Substring + lookup]  sum=6,963,210  median=23.4 ms  allocated=7,812 KB

Seven and a half megabytes of keys, none of which outlived a single if. On a busy endpoint that's 7.5 MB of garbage per call for the collector to sweep up later, and the collector's bill lands on some other request's latency, which is what makes this kind of thing so annoying to track down.

The alternate lookup

Since .NET 9, Dictionary<TKey, TValue> can hand you an alternate lookup keyed by a different, comparer-compatible type. For a string-keyed dictionary the useful one is ReadOnlySpan<char>. You ask for it once, then look up spans directly — no substring, no allocation:

var lookup = table.GetAlternateLookup<ReadOnlySpan<char>>();

ReadOnlySpan<char> span = input;
int start = 0;
for (int i = 0; i <= span.Length; i++)
{
    if (i == span.Length || span[i] == ' ')
    {
        ReadOnlySpan<char> token = span.Slice(start, i - start);   // no alloc
        if (lookup.TryGetValue(token, out long w)) sum += w;
        start = i + 1;
    }
}

Slice doesn't copy anything — it's a window over the original string's characters. The comparer hashes and compares the span against the stored keys without ever building a temporary string. Same dictionary, same entries, just a second door into it. And the numbers:

[B: span alternate lookup] sum=6,963,210  median=14.9 ms  allocated=0 KB
same result: True
allocation ratio A/B: ~200,000x
time ratio A/B: 1.57x

Identical sum, so I didn't quietly change behavior. Zero bytes allocated for the keys. And it came out about 1.57x faster too, which I honestly didn't expect to be that pronounced. I went in for the allocations and the wall-clock win was a bonus, mostly from skipping 140,000 string constructions and the memory traffic they drag along.

The catch nobody mentions

GetAlternateLookup isn't free to reach for. It only works when the dictionary's comparer implements IAlternateEqualityComparer<ReadOnlySpan<char>, string>. The good news is that the comparers you'd actually pick for machine keys already do: StringComparer.Ordinal, StringComparer.OrdinalIgnoreCase, and the default comparer you get from new Dictionary<string, long>() all qualify. A custom IEqualityComparer<string> you wrote yourself will not, and you find out with an exception thrown at the GetAlternateLookup call, not a compile error. So it's a runtime contract, and that's worth a test.

My honest opinion: this is a hot-path tool, not a default. If you're looking up a handful of keys, or the strings already exist as string objects, reach for it and you've added ceremony for nothing. Where it earns its keep is exactly the shape above, where you're carving keys out of a larger buffer (a parser, a tokenizer, a CSV or header scanner, a log processor) and the substring is pure waste because it dies the instant the lookup returns. That's when 7.8 MB quietly turns into zero.

I've started grepping my own parsers for Substring( followed by a TryGetValue on the next line. It's a small pattern, but it shows up more than you'd think once you know its silhouette.

Full runnable sample: https://github.com/ssukhpinder/dev-to-code-samples/tree/main/023-dictionary-alternate-lookup

Have you found a spot in your code where the key was already sitting in a buffer you owned? I'd like to hear where it turned up for you.

— still benchmarking things nobody asked me to

I Hashed Every Word Twice to Count It Once

Sukhpinder Singh — Tue, 04 Aug 2026 07:11:08 +0000

I was profiling a log parser last week. Nothing dramatic, it just counts how often each error code shows up in a day of lines. The hot loop is a dictionary bump: see a code, increment its counter. It's the most boring code in the file. It also sat higher in the profiler than I expected, so I went looking, and the reason turned out to be almost funny.

Here's the loop, more or less how everyone writes it:

if (counts.TryGetValue(code, out int c))
    counts[code] = c + 1;
else
    counts[code] = 1;

Reads exactly like what you mean. And it hashes the key twice. TryGetValue computes the hash, walks the bucket, finds the entry. Then counts[code] = ... throws all of that away and does the whole thing over to write. Same key, same hash, same bucket walk, twice per token. On the miss path it's the same story: one lookup to fail, another to insert.

There's a method that skips the second trip. CollectionsMarshal.GetValueRefOrAddDefault finds or creates the slot once and hands you a ref pointing straight into it:

ref int slot = ref CollectionsMarshal.GetValueRefOrAddDefault(counts, code, out _);
slot++;

One hash, one bucket walk, then you mutate the storage in place. If the key was missing it gets added as default(int), which is 0, so the first slot++ lands it at 1. The out bool tells you whether the key already existed. I don't need that here, so I throw it away.

The measurement

I wanted a real number, so I built a small counter over 5 million tokens drawn from a 20,000-word vocabulary, skewed so a handful of words dominate and there's a long rare tail. Roughly what actual text looks like. Both versions run the same input. I assert the two histograms come out identical first, then time each as the median of 11 runs. Allocations come from GC.GetAllocatedBytesForCurrentThread. Workstation GC, small Linux container. This isn't a lab and I'm not chasing microseconds, I care about the ratio.

tokens: 5,000,000, distinct vocab: 20,000

identical results: True  (distinct keys: 20,000)

TryGetValue + indexer (two lookups)        median   160.0 ms   ~   1,914 KB/run
GetValueRefOrAddDefault (one lookup)       median    95.0 ms   ~   1,914 KB/run

About 1.7x faster on the loop, and it held every run I did. The two-lookup version bounced between 157 and 170 ms. The ref version parked around 95.

Now the part I actually like, because it's the honest part. Look at the allocations column. They're identical. Both build the same dictionary, same 20,000 string keys, same backing arrays. GetValueRefOrAddDefault doesn't save you a single byte. It's not a memory trick. All it removes is CPU: the redundant hash and probe on every one of those 5 million bumps. If your workload is allocation-bound, this changes nothing for you. If it's counting or aggregating in a tight loop, it's most of the cost.

Why the gap is that big

The saving scales with how often you land on a key that already exists. In a Zipf-ish corpus most tokens are repeats, so most iterations take the "found it" path, which is the exact path where the naive version pays for two full lookups. Feed it 5 million unique keys instead and the gap shrinks, because the add path does real work either way. The win is proportional to your update-to-insert ratio, and counters live at the far update-heavy end of that. That's why this one shows off so well and a mostly-insert workload wouldn't.

There's a sharp edge here, and it's worth saying out loud. The ref you get back points directly into the dictionary's internal storage, and it stays valid only until the next structural change. Add or remove a key while you're still holding that ref and it can dangle. After a resize you might be writing into the wrong slot entirely. So the rule is simple: grab the ref, mutate it, let it go. Don't stash it, don't hold it across another insert into the same dictionary. For a bump-in-place loop that's how you'd naturally write it anyway, which is exactly why counters fit and a dictionary you're rewriting mid-iteration does not.

One more caution before you sprinkle this everywhere. The namespace is CollectionsMarshal. That word is telling you it's the low-level door. For a dictionary you touch a few hundred times, TryGetValue is clearer and nobody will ever measure the difference. My honest take is that the ref version earns its keep only when the counter loop is genuinely hot, which for me means parsing and aggregation. Everywhere else readability wins and I leave the boring version exactly where it is.

Full runnable sample: https://github.com/ssukhpinder/dev-to-code-samples/tree/main/022-dictionary-ref-upsert

What's the hottest dictionary loop in your codebase, and have you ever actually counted the lookups it does? I'd be curious whether the ratio holds on real data.

— still timing loops nobody asked me to time

The Feature Flag That Needed a Restart

Sukhpinder Singh — Mon, 03 Aug 2026 08:13:49 +0000

I flipped a feature flag in appsettings.json on a running service, curled the endpoint, and got the old behavior back. Flipped it again. Saved harder. Still off. So I did what apparently was tradition on that team: restarted the app, watched the flag come on, and moved on with my day. For months my mental model was "config reload is flaky". The reload was working the entire time. My code was reading the config through an interface that only ever looks once.

One section, four readers

To pin down exactly who notices a config edit, I built the smallest ASP.NET Core app that could answer the question. One Features section, one options class, four endpoints reading it four different ways — three interfaces plus the trap version I'll get to.

var builder = WebApplication.CreateBuilder(args);

builder.Services.Configure<FeatureOptions>(builder.Configuration.GetSection("Features"));
builder.Services.AddSingleton<ExportService>();

var app = builder.Build();

app.MapGet("/options",  (IOptions<FeatureOptions> o)         => Show("IOptions", o.Value));
app.MapGet("/snapshot", (IOptionsSnapshot<FeatureOptions> o) => Show("IOptionsSnapshot", o.Value));
app.MapGet("/monitor",  (IOptionsMonitor<FeatureOptions> o)  => Show("IOptionsMonitor", o.CurrentValue));
app.MapGet("/frozen",   (ExportService s)                    => Show("frozen singleton", s.Frozen));

app.Services.GetRequiredService<IOptionsMonitor<FeatureOptions>>()
    .OnChange(o => Console.WriteLine($"[reload] Features changed: ExportEnabled={o.ExportEnabled}"));

app.Run();

Start it, hit all four endpoints, and everyone agrees:

IOptions           ExportEnabled=False MaxPageSize=50
IOptionsSnapshot   ExportEnabled=False MaxPageSize=50
IOptionsMonitor    ExportEnabled=False MaxPageSize=50
frozen singleton   ExportEnabled=False MaxPageSize=50

Then, with the app still running, I edited appsettings.json — ExportEnabled to true, MaxPageSize to 200 — and curled again:

IOptions           ExportEnabled=False MaxPageSize=50
IOptionsSnapshot   ExportEnabled=True MaxPageSize=200
IOptionsMonitor    ExportEnabled=True MaxPageSize=200
frozen singleton   ExportEnabled=False MaxPageSize=50

Same file, same section, same running process. Two readers saw the change, two never will. That split is the entire topic.

Why IOptions never looks twice

IOptions<T> is a singleton that binds the section on first use and caches the result for the lifetime of the process. No change tokens, no invalidation, nothing. It's not broken; it's just answering a different question — "what was the config when this process warmed up?" My flag bug was exactly this. The reload pipeline delivered the new value and IOptions had no reason to care.

IOptionsSnapshot<T> is scoped, so it re-binds once per request. IOptionsMonitor<T> is a singleton that subscribes to configuration change tokens, keeps CurrentValue up to date, and gives you OnChange. Both picked up my edit without a single line of plumbing, because WebApplication.CreateBuilder already registers appsettings.json with reloadOnChange: true. The machinery you'd think you need to build is on by default; the only decision left is which interface you inject, and that's the one nobody thinks about.

One caveat from the trenches: reload depends on file-change notifications actually arriving. In my container a plain in-place edit triggered OnChange exactly once, which is the polite case — editors that save via rename-and-replace can make it fire twice, and on some mounted or network file systems events never arrive and you need DOTNET_USE_POLLING_FILE_WATCHER=1. Kubernetes ConfigMap symlink swaps are their own adventure. Test the notification path in your real environment before you bet a prod flag flip on it.

The version that actually got me

Here's the part I find sneaky. You can lose the reload while holding the correct interface:

public sealed class ExportService(IOptionsMonitor<FeatureOptions> monitor)
{
    // Right interface, wrong moment: CurrentValue read once, kept forever.
    public FeatureOptions Frozen { get; } = monitor.CurrentValue;
}

That's the /frozen endpoint above, stale forever, with IOptionsMonitor sitting right there in the constructor. Reading CurrentValue at construction time turns a live monitor back into IOptions with extra steps. The fix is boring: keep the monitor in the field and read CurrentValue where you use it, or subscribe with OnChange if you need to react. Code review barely catches this one because the injection looks textbook.

What snapshot's freshness costs

Snapshot re-binds every request, and binding is reflection over your options type. I wanted a number for that, so the sample has a /bench endpoint: 100,000 iterations each of creating an empty scope, creating a scope and resolving a snapshot, and reading monitor.CurrentValue. This is a container, best of three runs, and I care about ratios, not absolutes:

100,000 iterations:
  empty scope               19.0 ms
  scope + snapshot bind    715.7 ms
  monitor.CurrentValue       2.1 ms

So a scope-plus-bind lands around 7 µs while a CurrentValue read is around 20 ns — roughly 300× apart, and the empty-scope row shows it's the binding, not the scope, doing the damage. Honest reading: 7 µs per request for one options type will never show up on your dashboard. Multiply by a dozen options classes injected across every request and it's still small. Pick by lifetime semantics, not this benchmark.

My actual rule, stated as the opinion it is: IOptionsMonitor in singletons and pretty much everywhere else too, IOptionsSnapshot only when a request must see one consistent value from the first middleware to the last log line mid-reload, and plain IOptions when the value is genuinely fixed at boot. And if your config only ever changes at deploy time — env vars, immutable images, the works — skip the whole question. Env var changes don't hot-reload anyway, and IOptions everywhere is the cheapest and most honest description of how your system behaves.

Full runnable sample, live-edit demo included: https://github.com/ssukhpinder/dev-to-code-samples/tree/main/021-options-reload-lifetimes

What's your house rule — snapshot everywhere, monitor everywhere, or restart-and-pretend? And has per-request consistency ever actually saved you mid-reload? Tell me in the comments, because I've never caught it in the act.

— still flipping flags nobody asked me to flip

One Outage, Four Times the Traffic

Sukhpinder Singh — Mon, 03 Aug 2026 07:15:21 +0000

The graph that kicked this off: a downstream inventory service wobbled for about two seconds, and our outbound request count to it quadrupled in exactly that window. No user spike. No deploy. The extra traffic was us — my own retry loop, faithfully doing what I told it to do years ago: "try it four times, it's probably transient."

So I rebuilt the incident in miniature. One self-hosted endpoint that returns 503 while a fake outage is active, twenty concurrent callers, and a stopwatch. One process on localhost in a Linux container, .NET 10, delays shrunk so the whole thing fits in seconds — not a lab, I care about the shapes, not the milliseconds.

The loop I used to write

You've seen this loop. Odds are you've written this loop. I've written it more times than I'll admit in public:

for (var attempt = 1; ; attempt++)
{
    var resp = await http.GetAsync("/inventory");
    if (resp.IsSuccessStatusCode) return true;
    if (attempt == 4) return false;
    // no delay — "it's probably transient"
}

Twenty concurrent calls, two-second outage:

== phase 1: hand-rolled retry x4, no delay (outage 2s) ==
client calls :   20    succeeded:   0    failed: 20
server hits  :   80    during outage: 80    after recovery: 0
hit window   : first at      4 ms, last at     33 ms
wall time    : 0.03 s

Read that hit window again. All four attempts, for all twenty callers, landed within 29 milliseconds. The outage lasted two seconds. So my loop generated four times the traffic, aimed every single request at a service that was down, and bought exactly zero extra successes.

That's the quiet flaw in naive retries: they finish before the problem does. A dependency that's down for two seconds might as well be down forever if your entire retry budget burns in 30 milliseconds. And you pay twice — once as wasted work on your side, once as extra load on the exact service that's trying to stand back up.

Same budget, actually spread out

.NET ships a proper answer as a NuGet package: Microsoft.Extensions.Http.Resilience, built on Polly v8. One line on the client registration:

builder.Services.AddHttpClient("backoff", c => c.BaseAddress = new Uri("http://127.0.0.1:5199"))
    .AddStandardResilienceHandler(o =>
    {
        o.Retry.Delay = TimeSpan.FromMilliseconds(500); // production default is 2s; shrunk for the demo
    });

The call site collapses to a single await — the handler owns the retries (three by default), exponential backoff with jitter, per-attempt and total timeouts, and a circuit breaker I'll get to in a minute.

Same twenty calls, same two-second outage:

== phase 2: standard handler, exponential backoff (base 500ms, outage 2s) ==
client calls :   20    succeeded:  13    failed: 7
server hits  :   80    during outage: 67    after recovery: 13
hit window   : first at      1 ms, last at   2741 ms
wall time    : 2.74 s

Here's the part I find genuinely elegant: the request budget is identical. Eighty hits, same as the naive loop. The only thing that changed is where those hits landed in time — spread across 2.7 seconds instead of crammed into 29 milliseconds — and that alone pushed 13 of 20 calls through, because their later attempts outlived the outage. Jitter wobbles the exact split; a back-to-back run gave me 12 of 20, and seven callers still spent their last attempt inside the window. Retries don't help because you try harder. They help when an attempt lands after recovery. Backoff is what buys you that.

Stop knocking on a dead door

Backoff handles the two-second blip. But if the outage runs long, even polite retries are pure cost — every attempt burns your threads and their recovery capacity. That's the circuit breaker's job. The standard handler has one on by default; I tuned it down so 40 demo calls can trip it (the default MinimumThroughput of 100 is sized for real traffic, and rightly so):

.AddStandardResilienceHandler(o =>
{
    o.Retry.Delay = TimeSpan.FromMilliseconds(200);
    o.AttemptTimeout.Timeout = TimeSpan.FromSeconds(2);
    o.CircuitBreaker.FailureRatio = 0.5;
    o.CircuitBreaker.MinimumThroughput = 20;
    o.CircuitBreaker.SamplingDuration = TimeSpan.FromSeconds(10);
    o.CircuitBreaker.BreakDuration = TimeSpan.FromSeconds(2);
});

Forty calls into a six-second outage:

== phase 3: standard handler + circuit breaker (longer outage: 6s) ==
client calls :   40    succeeded:   0    failed: 40
server hits  :   40    during outage: 40    after recovery: 0
hit window   : first at      6 ms, last at     18 ms
wall time    : 0.29 s
failures     : BrokenCircuit (failed fast) x40

probe after recovery : 200 OK — circuit closed itself, no restarts, no config

The naive loop would have thrown 160 requests at that outage. The breaker allowed 40 — the first attempts — saw the failure ratio, opened, and every pending retry failed instantly with BrokenCircuitException instead of queuing up for another knock. Everything resolved in 0.29 seconds. Nothing piled up. The dependency got silence to recover in. And once the break duration passed, a single probe went through half-open, got its 200, and the circuit closed itself.

My opinion, stated as one: a hand-rolled retry loop in a PR should trigger the same reflex as hand-rolled JSON parsing. Not because the loop is hard to write, but because the loop is easy to write badly in ways that only show up during an incident — which is the one time you really don't want surprises.

Where I'd hold back

Retrying a GET is safe. Retrying a POST that charges a card is not "probably transient", it's "possibly twice" — think before wrapping non-idempotent calls, and lean on idempotency keys if you must. Don't copy my demo thresholds to production either; I shrank them so you can watch the breaker trip on localhost, and the real defaults are conservative on purpose. And an open circuit doesn't make failure go away — it makes failure fast. You still owe callers a fallback: a cached value, a sensible default, or an honest 503 of your own. If you don't have one, the breaker just relocates your problem.

Full runnable sample: https://github.com/ssukhpinder/dev-to-code-samples/tree/main/020-httpclient-retry-storm

What's living in your codebase right now — the loop or the handler? If you've survived an actual retry storm (or caused one, no judgment), I'd like to hear how you found it.

— Sukhpinder, still staging outages nobody asked me to

I Loaded 8,956 Rows to Flip One Boolean

Sukhpinder Singh — Sun, 02 Aug 2026 08:13:03 +0000

Every system I've worked on has a nightly job shaped like this: archive delivered orders older than 90 days. Mine was four lines of EF Core that had survived a dozen code reviews, several of them mine. Then I ran it with SQL logging switched on and watched it haul 8,956 complete rows out of the database so it could write 8,956 booleans back. Nobody read those rows. They existed for the length of a foreach and died.

I wanted the actual bill, not a feeling, so I measured it.

The habit

The demo table is 20,000 orders in SQLite, seeded with Random(42) so every run produces the same data. 8,956 of them match the archive predicate. A DbCommandInterceptor counts every command EF Core sends, timings are the median of 5 rounds after a warmup, and allocations come from GC.GetAllocatedBytesForCurrentThread. EF Core 10, Release build, small Linux container, in-process SQLite. Not a lab — I care about the ratios.

Here's the version of the job I'd been writing since EF Core 1:

var stale = ctx.Orders
    .Where(o => o.Status == OrderStatus.Delivered && o.PlacedAtUtc < cutoffUtc)
    .ToList();

foreach (var order in stale)
    order.IsArchived = true;

ctx.SaveChanges();

It reads like exactly what you mean, which is why it survives code review. And for five rows it's fine. Here's what it costs for 8,956:

[A: load entities + SaveChanges]
  rows touched   : 8,956
  SQL commands   : 8,957
  median time    : 355.3 ms
  allocated      : 75,143 KB

That command count isn't a typo. One SELECT to fetch the rows, then one UPDATE per order — the SQLite provider ships each as its own command. SQL Server would batch them into multi-statement round trips, which helps, but EF still generates, ships, and executes one UPDATE statement per row. WHERE "Id" = @p0, 8,956 times.

The 75 MB is the part that surprised me more. Materializing 8,956 entities doesn't cost that much on its own. Change tracking does: EF snapshots every property of every tracked entity so SaveChanges can diff them later. Two full copies of the table's matching slice, held in memory, to change one column whose new value I already knew before the query ran.

The one-statement version

EF Core has had a set-based answer since EF 7, and I'd been treating it as an exotic tool instead of the obvious one:

var archived = ctx.Orders
    .Where(o => o.Status == OrderStatus.Delivered && o.PlacedAtUtc < cutoffUtc)
    .ExecuteUpdate(s => s.SetProperty(o => o.IsArchived, true));

[B: ExecuteUpdate]
  rows touched   : 8,956
  SQL commands   : 1
  median time    : 10.6 ms
  allocated      : 68 KB

Same predicate, same 8,956 rows changed, one command. This is the SQL the interceptor caught:

UPDATE "Orders" AS "o"
SET "IsArchived" = @p
WHERE "o"."Status" = 1 AND "o"."PlacedAtUtc" < @cutoffUtc

33x faster and roughly 1,100x fewer allocations, and remember my numbers have no network in them — SQLite is in-process. On a real connection, strategy A pays latency per round trip while strategy B still pays it once. The gap you'd see in production is wider than mine, not narrower.

There's no magic here, and that's sort of the point. The database could always do this in one statement. The load-modify-save pattern was me routing a one-line UPDATE through a full object graph because that's the shape the framework made comfortable.

Where it bites

ExecuteUpdate goes around the change tracker entirely. That's the whole trick, and it's also the sharp edge:

var tracked = ctx.Orders.First(o => o.Status == OrderStatus.Delivered
                                 && o.PlacedAtUtc < cutoffUtc);

ctx.Orders
   .Where(o => o.Status == OrderStatus.Delivered && o.PlacedAtUtc < cutoffUtc)
   .ExecuteUpdate(s => s.SetProperty(o => o.IsArchived, true));

== the stale-tracker gotcha ==
  tracked entity says IsArchived = False
  database says       IsArchived = True

The tracked entity never hears about the update. If code later in that request reads tracked.IsArchived, it gets a confident wrong answer, and if SaveChanges runs afterwards for an unrelated edit, nothing corrects it. Mixing tracked work and set-based updates on the same data in the same context is where the bugs live.

When I still load the entities

There are real reasons to keep the old pattern, and they're worth naming rather than waving at. If flipping the flag triggers per-entity behavior — domain events, an audit interceptor on SaveChanges, business rules that can veto individual rows — ExecuteUpdate skips all of it. It ignores optimistic concurrency tokens too: last write wins, silently. And each ExecuteUpdate runs as its own implicit transaction, so if the job needs to be atomic with other changes, you're wrapping it in an explicit one yourself.

My rule after this experiment, stated as the opinion it is: load-modify-save is for entities with behavior, and it earns its cost a handful of rows at a time. Any query that ends in "load them all, set one property, save" is a maintenance job, and maintenance jobs speak SQL. Let them.

The delete side is the same story with a shorter name. Purging old cancelled orders went from a fetch-and-remove loop to:

var purged = ctx.Orders
    .Where(o => o.Status == OrderStatus.Cancelled && o.PlacedAtUtc < purgeCutoff)
    .ExecuteDelete();

2,086 rows gone in 23.7 ms, one command, nothing materialized.

Full runnable sample: https://github.com/ssukhpinder/dev-to-code-samples/tree/main/019-efcore-execute-update

Got a nightly job that fetches everything it's about to overwrite? Run it with an interceptor counting commands and tell me your number in the comments — I'll admit mine was embarrassing for years.

— still benchmarking things nobody asked me to, 8,956 statements at a time

The Factory Class I Finally Deleted

Sukhpinder Singh — Sun, 02 Aug 2026 07:14:50 +0000

The PR added a WhatsApp notification channel. Three changes: a new WhatsAppSender class, fair. Its registration, fair. And NotificationSenderFactory, where a switch statement quietly grew its fourth arm. I've been approving some version of that third change since 2016 — different codebases, same class, same switch. Keyed services made it deletable back in .NET 8, and this week, on .NET 10, I finally sat down and deleted it.

The class in question

You've written this class. Maybe you called it a factory, maybe a resolver, maybe a provider. One interface, a few implementations, and a string deciding who does the work:

public sealed class NotificationSenderFactory(IServiceProvider sp)
{
    public INotificationSender Create(string channel) => channel switch
    {
        Channels.Email => sp.GetRequiredService<EmailSender>(),
        Channels.Sms => sp.GetRequiredService<SmsSender>(),
        Channels.Push => sp.GetRequiredService<PushSender>(),
        _ => throw new ArgumentException($"Unknown channel '{channel}'.", nameof(channel)),
    };
}

There are only two ways to write this class and both are a little embarrassing. Either the factory news up the senders itself, which makes every constructor dependency the senders have the factory's problem too. Or it wraps IServiceProvider like mine does, which is the service locator pattern wearing a name tag that says "factory". And the registration tax rides along: every concrete type registered so the factory can pull it back out, plus the factory itself.

builder.Services.AddScoped<EmailSender>();
builder.Services.AddScoped<SmsSender>();
builder.Services.AddScoped<PushSender>();
builder.Services.AddScoped<NotificationSenderFactory>();

Four registrations, one extra class, zero business value.

Three lines instead

Keyed services collapse the whole arrangement into registrations that carry the key themselves. (Autofac folks, I know, you've had named services since forever. The rest of us stayed on the built-in container and waited.)

builder.Services.AddKeyedScoped<INotificationSender, EmailSender>(Channels.Email);
builder.Services.AddKeyedScoped<INotificationSender, SmsSender>(Channels.Sms);
builder.Services.AddKeyedScoped<INotificationSender, PushSender>(Channels.Push);

Consumption has two flavors. When the call site already knows which implementation it wants, an attribute says so. When the key only exists at runtime — a route value, a message header — you ask by key:

// the endpoint declares which implementation it wants
app.MapPost("/notify/email", ([FromKeyedServices(Channels.Email)] INotificationSender sender) =>
    Results.Ok(new { channel = Channels.Email, result = sender.Send("build is green") }));

// or the route decides at runtime
app.MapPost("/notify/{channel}", (string channel, IServiceProvider sp) =>
    Results.Ok(new { channel, result = sp.GetRequiredKeyedService<INotificationSender>(channel).Send("build is green") }));

Yes, the runtime-key endpoint still touches IServiceProvider. When the key arrives at runtime, somebody has to do a lookup. The difference is that the mapping now lives in the registrations instead of a second class that can drift away from them.

My demo app probes itself with HttpClient (.NET 10, small Linux container — this is behavior, not benchmarks) and the exchanges are exactly what you'd hope:

== keyed services ==
POST /notify/email      -> 200 {"channel":"email","result":"email queued: \"build is green\""}
POST /notify/push       -> 200 {"channel":"push","result":"push queued: \"build is green\""}
POST /digest            -> 200 {"result":"email queued: \"your daily digest\""}

That /digest line matters more than it looks. Behind it sits a plain class taking one specific keyed implementation through its constructor. No factory, no locator, and the class states its actual dependency instead of hiding it behind a resolver:

public sealed class DailyDigestService([FromKeyedServices(Channels.Email)] INotificationSender email)
{
    public string SendDigest() => email.Send("your daily digest");
}

The part that bit me

I added a diagnostics block to the demo because two behaviors surprised me the first time I hit them. Real output:

== what the container actually sees ==
GetServices<INotificationSender>()          -> 0 implementations
GetKeyedServices(KeyedService.AnyKey)       -> EmailSender, SmsSender, PushSender
GetRequiredKeyedService("fax")              -> InvalidOperationException: No keyed service for type 'INotificationSender' using key type 'System.String' has been registered.

First: keyed registrations are invisible to plain enumeration. Inject IEnumerable<INotificationSender> for some broadcast-to-every-channel feature and you get an empty sequence. No exception, no warning, just a loop that iterates nothing. GetKeyedServices<T>(KeyedService.AnyKey) is the escape hatch that actually sees them all.

Second, read that exception message closely. It names the service type and the key's type. It does not name the key. "fax" appears nowhere in it. My old factory's default arm was my code, so the message included the offending value. Now I log the key at the call site before resolving, because "using key type 'System.String'" narrows the suspect list down to every string in the system.

When the factory stays

Keyed services map a key to a registration, and that's the entire trick. If your factory contains actual logic — construction that depends on config, parameters passed at creation time, pooling — it's earning its keep. Leave it alone. Same if you have one implementation chosen once at startup by environment: register the right one conditionally and skip keys entirely.

And it's still runtime resolution. A typo'd key compiles clean and fails as a 500 in production, exactly like the factory's default arm did. My rule now, stated as opinion: keys live in a consts class (Channels.Email, never "email" sprinkled around), and one test walks every routable key and resolves it. Costs three minutes to write, catches the dumb thing forever.

The switch statement was never evil. It just lived in a class whose only job was to exist between my endpoints and my registrations, and the built-in container has been willing to do that job since .NET 8. Deleting a whole class in a PR feels better than adding one. Every time.

Full runnable sample: https://github.com/ssukhpinder/dev-to-code-samples/tree/main/018-keyed-di-services

What's the ceremony class you keep rewriting in every codebase? I'll go first, obviously — factories. Tell me yours in the comments.

— still deleting classes nobody asked me to

My Shell Scripts Speak C# Now

Sukhpinder Singh — Sat, 01 Aug 2026 09:22:49 +0000

Every couple of weeks I need a twenty-line program. Find what's bloating a build agent's disk, dedupe a CSV, hash-check a folder. For fifteen years the honest answer to "which language?" was not C# — by the time I'd done mkdir, dotnet new console, and named yet another throwaway csproj, the moment had passed. So those little jobs went to bash or Python, and I grumbled quietly every time.

.NET 10 removed the ritual. You write one .cs file and run it. I'd been meaning to check how well this actually holds up for real scripts, so this week I did — nothing fancy, one Linux container and a stopwatch.

One file, no project

Here's biggest.cs, a small utility that lists the largest files under a directory. The whole program is this one file — no csproj anywhere:

#!/usr/bin/env dotnet
#:package Humanizer@3.0.10

using Humanizer;

var root = args.Length > 0 ? args[0] : ".";
var top = args.Length > 1 && int.TryParse(args[1], out var n) ? n : 10;

var files = new DirectoryInfo(root)
    .EnumerateFiles("*", new EnumerationOptions
    {
        RecurseSubdirectories = true,
        IgnoreInaccessible = true,
        AttributesToSkip = FileAttributes.ReparsePoint
    })
    .OrderByDescending(f => f.Length)
    .Take(top)
    .ToList();

foreach (var f in files)
{
    var size = f.Length.Bytes().Humanize("#.#");
    var age = (DateTime.UtcNow - f.LastWriteTimeUtc).Humanize();
    Console.WriteLine($"{size,10}  {f.FullName}  (modified {age} ago)");
}

Two lines are new. #:package Humanizer@3.0.10 is a NuGet reference written as a directive, right in the source. The shebang we'll get to in a minute. Everything else is the C# you already write, top-level statements and all.

$ dotnet run biggest.cs -- ~/.dotnet 5

Top 5 files under /root/.dotnet:

   37.6 MB  .../FSharp.Compiler.Service.dll  (modified 46 seconds ago)
   18.7 MB  .../Microsoft.CodeAnalysis.CSharp.dll  (modified 46 seconds ago)
   18.7 MB  .../Roslyn/bincore/Microsoft.CodeAnalysis.CSharp.dll  (modified 45 seconds ago)
   14.9 MB  .../System.Private.CoreLib.dll  (modified 45 seconds ago)
   11.4 MB  .../native/singlefilehost  (modified 47 seconds ago)

Total: 101.1 MB

Yes, the .NET SDK's biggest file is the F# compiler. I enjoyed that more than I should have.

The stopwatch part

The obvious worry: is this Python-fast to iterate on, or does every run pay the compiler tax? I timed it on SDK 10.0.302 in a Linux container — not a lab, I care about the ratios, and warm numbers are best of three.

The first ever run took 10.5 seconds. That's the worst case by design: it restored Humanizer, compiled, and even sat through the CLI's first-run welcome banner. After that, an unchanged script runs in about 0.3 seconds, and rerunning right after an edit lands just under half a second. Half a second from save to output is firmly in scripting territory. I stopped noticing the compiler was there, which is the whole point.

The other thing I checked: my folder still contains exactly one file. No bin/, no obj/. The build products get squirreled away under ~/.local/share/dotnet/runfile/, one content-hashed folder per script, so the place where your script lives stays as clean as a bash script's folder would. dotnet biggest.cs works too, if typing run offends you.

chmod +x, because why not

That shebang line isn't decoration:

$ chmod +x biggest.cs
$ ./biggest.cs /tmp 3

   22.3 MB  /tmp/phantomjs/phantomjs-2.1.1-linux-x86_64.tar.bz2  (modified 12 weeks ago)
   ...

A C# file behaving like a first-class shell script, cron-able and CI-able. My opinion, stated as such: for anything past one pipe and a grep, I'd now rather have this than the pile of bash I used to babysit. String handling in bash is where my weekends go to die, and every one of those scripts is one #:package away from a real JSON parser or a real HTTP client.

Where the party ends

It's genuinely single-file, at least on the SDK I tested. I dropped a Helper class into a util.cs next to my script and got error CS0103: The name 'Helper' does not exist in the current context. Running a file compiles that file, full stop.

I've decided I like the bluntness, because wanting a second file is exactly the signal that your script stopped being a script. The graduation path is one command:

$ dotnet project convert biggest.cs

That generates a biggest/ folder with the source and a proper csproj, shebang and directives stripped, the #:package line turned into a real PackageReference. Funny detail: the generated project came with PublishAot and PackAsTool already set to true — the SDK has strong opinions about what your script wants to grow into.

When not to use this: anything a teammate maintains with you, anything that needs tests, anything with more than one file's worth of ideas. And remember that cold start — 10 seconds of restore on first run means ephemeral CI containers pay the tax every time unless you cache the NuGet folder.

But for the twenty-line jobs? I've stopped reaching for Python. Ten seconds once, a third of a second forever after, and it's the language I actually think in.

Full runnable sample: https://github.com/ssukhpinder/dev-to-code-samples/tree/main/016-file-based-csharp

What's the smallest job you've ever created an entire solution for? Mine involved three lines and a .sln file I'm still ashamed of. Tell me yours in the comments.

— still timing things nobody asked me to time

Upgrade .NET 8 to .NET 10 Without Breaking Your API Contract

Sukhpinder Singh — Sat, 01 Aug 2026 03:04:43 +0000

If I need to upgrade .NET 8 to .NET 10, I treat the work as an API contract migration, not a project-file edit. A service can compile, pass unit tests, and still surprise consumers with a changed JSON shape, status code, authentication response, or OpenAPI document.

That risk matters now because Microsoft has confirmed that .NET 8 and .NET 9 reach end of support on November 10, 2026. .NET 10 and C# 14 are the current stable releases, and .NET 10 is the supported LTS destination.

Why the deadline changes my upgrade order

My first step is inventory, not retargeting. I list every deployable project, test project, global.json, container base image, CI SDK pin, and Microsoft package reference. dotnet --list-sdks shows what a machine can build; dotnet --info shows what the current environment actually resolves.

If that inventory needs more detail, my older guide to dotnet sdk check is a useful starting point. For APIs still on .NET 8, the broader Web API setup and security checklist can help identify behavior worth protecting before the move.

I then separate the migration into three changes: SDK and target framework, NuGet dependencies, and runtime infrastructure. Keeping those changes visible makes a failure easier to locate. A giant dependency-refresh commit may be quick to create, but it is hard to diagnose.

Upgrade .NET 8 to .NET 10 behind contract tests

Before changing net8.0, I add a small set of tests around the endpoints consumers cannot tolerate changing. I care about observable behavior: status codes, content types, required JSON names, and authentication boundaries. I avoid asserting an entire serialized string because harmless property ordering can make that test noisy.

Here is a focused xUnit test for a Minimal API:

using System.Net;
using System.Text.Json;
using Microsoft.AspNetCore.Mvc.Testing;
using Xunit;

public sealed class ProductContractTests(
    WebApplicationFactory<Program> factory)
    : IClassFixture<WebApplicationFactory<Program>>
{
    [Fact]
    public async Task GetProduct_keeps_the_public_contract()
    {
        using var client = factory.CreateClient(new()
        {
            BaseAddress = new Uri("https://localhost")
        });

        using var response = await client.GetAsync("/products/42");

        Assert.Equal(HttpStatusCode.OK, response.StatusCode);
        Assert.Equal(
            "application/json",
            response.Content.Headers.ContentType?.MediaType);

        await using var stream =
            await response.Content.ReadAsStreamAsync();
        using var json = await JsonDocument.ParseAsync(stream);

        Assert.Equal(
            42,
            json.RootElement.GetProperty("id").GetInt32());
        Assert.True(json.RootElement.TryGetProperty("name", out _));
    }
}

The test project references Microsoft.AspNetCore.Mvc.Testing in the same 10.0 servicing line as the application. This one test is not a complete compatibility suite. It is a template for the small number of contracts that matter most: a successful read, a validation failure, an unauthorized request, and a not-found response. Those checks catch behavioral changes that a unit test below the HTTP pipeline cannot see.

For a top-level Minimal API, I also expose the entry point to the test project:

app.Run();

public partial class Program
{
}

Microsoft maintains a complete .NET 10 WebApplicationFactory sample. I use that as the reference for test-host setup rather than creating custom server plumbing.

Move the runtime, packages, and pipeline together

With the baseline green, I change the application and test projects to net10.0. I update Microsoft.AspNetCore, Microsoft.Extensions, and EF Core packages to compatible 10.0 servicing releases, then inspect the official .NET 10 breaking-change catalog instead of guessing from compiler errors alone.

<PropertyGroup>
  <TargetFramework>net10.0</TargetFramework>
</PropertyGroup>

I run the same short sequence locally and in CI:

dotnet package list --outdated
dotnet restore
dotnet build --warnaserror
dotnet test
dotnet publish -c Release

The pipeline must install a .NET 10 SDK, and containerized services must use matching 10.0 build and runtime images. Updating only the developer machine proves very little about the artifact that reaches production.

OpenAPI deserves an explicit decision. ASP.NET Core 10's built-in generator emits OpenAPI 3.1 by default. If an existing client generator only understands 3.0, I temporarily pin the format and schedule that contract change separately:

builder.Services.AddOpenApi(options =>
{
    options.OpenApiVersion =
        Microsoft.OpenApi.OpenApiSpecVersion.OpenApi3_0;
});

That pin is a compatibility tool, not a reason to avoid OpenAPI 3.1 forever. I keep it only until consumers have been tested and upgraded.

When I would not use this direct path

A direct retarget is the wrong move when a database provider, authentication component, hosting platform, or commercial dependency does not support .NET 10. In that case, I isolate the blocker first. Moving through .NET 9 can help expose changes in smaller steps, but .NET 9 has the same November 2026 support deadline, so it is not the final destination.

I also avoid combining the runtime upgrade with an EF model redesign, authentication rewrite, or OpenAPI generator replacement. Those may all be worthwhile, but separate commits and deployments preserve a useful rollback boundary.

For shared libraries, temporary net8.0;net10.0 multi-targeting can let applications migrate independently. For a deployable API, multi-targeting is not a substitute for choosing and validating the runtime that production will execute.

Which API contract would you pin down before moving your service to .NET 10?

Thanks for reading ? see you next time.

The Test That Slept and the Test That Never Woke Up

Sukhpinder Singh — Thu, 30 Jul 2026 08:24:37 +0000

My retry tests took seven seconds each. Not because they did seven seconds of work — because they did seven seconds of nothing, waiting out real backoff delays with a real clock. So I did the textbook thing: injected TimeProvider, swapped in FakeTimeProvider, felt smug for about ninety seconds. Then my shiny new fast test didn't come back slow. It didn't come back at all.

This is the story of both tests: the one that slept, and the one that never woke up.

Seven seconds of nothing

The code under test is a bog-standard exponential backoff helper. Three transient failures, then success, with 1s, 2s and 4s waits in between. The honest way to test it against the system clock looks like this:

var retry = new TransientRetry(TimeProvider.System, maxAttempts: 4, baseDelay: TimeSpan.FromSeconds(1));
var calls = 0;

var result = await retry.ExecuteAsync(() =>
    ++calls < 4 ? throw new TimeoutException("flaky dependency")
                : Task.FromResult("ok"));

Assert.Equal(4, retry.Attempts);
// 1s + 2s + 4s of genuine wall-clock waiting:
Assert.True(sw.Elapsed >= TimeSpan.FromSeconds(7));

Passed Succeeds_after_three_transient_failures_real_clock [7 s]

Seven seconds, every run, forever. The test is correct and I resent it. Multiply by a give-up-path test, a jitter test, a cancellation test, and one small retry class quietly bills your CI half a minute per run. That's the sleep tax, and most suites pay it in a dozen places.

Owning the clock

Since .NET 8 the fix has been in the box. TimeProvider is the abstraction, and the only change my retry helper needed was accepting one and handing it to Task.Delay:

public sealed class TransientRetry(TimeProvider clock, int maxAttempts, TimeSpan baseDelay)
{
    public int Attempts { get; private set; }

    public async Task<T> ExecuteAsync<T>(Func<Task<T>> operation, CancellationToken ct = default)
    {
        var delay = baseDelay;
        while (true)
        {
            Attempts++;
            try { return await operation().ConfigureAwait(false); }
            catch (Exception) when (Attempts < maxAttempts)
            {
                await Task.Delay(delay, clock, ct).ConfigureAwait(false);
                delay *= 2;
            }
        }
    }
}

Production passes TimeProvider.System. Tests pass FakeTimeProvider from the Microsoft.Extensions.TimeProvider.Testing package and move time by hand:

var task = retry.ExecuteAsync(() =>
    ++calls < 4 ? throw new TimeoutException("flaky dependency")
                : Task.FromResult("ok"));

Assert.False(task.IsCompleted);          // parked on the 1s backoff
fake.Advance(TimeSpan.FromSeconds(1));   // attempt 2 fails, parks on 2s
fake.Advance(TimeSpan.FromSeconds(2));   // attempt 3 fails, parks on 4s
Assert.False(task.IsCompleted);          // mid-backoff assertion. Try writing THIS with Thread.Sleep.
fake.Advance(TimeSpan.FromSeconds(4));   // attempt 4 succeeds

Assert.Equal("ok", await task);

Seven virtual seconds, zero real ones. I ran exactly this in a console app first and it worked beautifully. Then I pasted it into the xunit project and dotnet test sat there until the hang detector shot the process.

The test that never woke up

Same code. Passes in a console app, deadlocks in xunit. I stuck a file-based trace into the test because at that point I trusted nothing, and it told the whole story:

[t5] started  calls=1  sc=AsyncTestSyncContext
[t5] after+1  calls=1  completed=False
[t5] after+2  calls=1  completed=False
[t5] after+4  calls=1  completed=False
[t9] attempt 2  sc=null      <- thread pool, AFTER all my advances

calls never moved while I advanced the clock. Attempt 2 eventually ran on a different thread, after all three Advance calls had already happened.

Here's the mechanism. When Advance() fires the timer, the await Task.Delay continuation is supposed to run right there, synchronously. But the .NET scheduler refuses to inline a continuation onto a thread whose SynchronizationContext.Current isn't null — and xunit v2 runs every test under its AsyncTestSyncContext. Yes, even with ConfigureAwait(false): that controls where the continuation goes, not whether the completing thread may run it inline. So the continuation gets queued to the thread pool, my test thread sprints through the remaining Advance calls, and only then does attempt 2 register its 2-second delay. Virtual now is already +7s; the new timer is due at +9s; nothing will ever advance the clock again. The test sleeps forever, which is a funny outcome for a test whose entire purpose was to stop sleeping.

The console app has no synchronization context, so everything inlines and the exact same code is deterministic. That's why my repro "proved" the code was fine.

The fix is one load-bearing line at the top of the test:

SynchronizationContext.SetSynchronizationContext(null);

Passed Same_scenario_fake_clock [36 ms]
Passed Gives_up_after_max_attempts_fake_clock [10 ms]

From 7 seconds to 36 milliseconds, and the mid-backoff Assert.False is now a real, deterministic assertion instead of a race I'd have lost one Friday a month. (Timings are xunit's own per-test numbers from a small Linux container — I care about seconds-versus-milliseconds, not the exact digits.)

If nulling the context feels too spicy for your codebase, the alternative is advancing in a loop — while (!task.IsCompleted) { fake.Advance(step); await Task.Yield(); } — which tolerates the thread hops but gives up the crisp step-by-step assertions. I prefer the one-liner and a loud comment.

The bug you can finally write down

The part I ended up liking most isn't the speed. FakeTimeProvider also lets you set the time zone, which means the whole class of "only fails at midnight in production" bugs becomes a normal, boring test:

// 18:20 UTC on July 30 == 23:50 in Kolkata (UTC+05:30)
var fake = new FakeTimeProvider(new DateTimeOffset(2026, 7, 30, 18, 20, 0, TimeSpan.Zero));
fake.SetLocalTimeZone(TimeZoneInfo.FindSystemTimeZoneById("Asia/Kolkata"));

var quota = new DailyQuota(fake, limit: 2);
// ...exhaust the quota at 23:50 local...
fake.Advance(TimeSpan.FromMinutes(20));  // 00:10 local — but still July 30 in UTC
Assert.True(quota.TryConsume());         // resets at LOCAL midnight, as promised

Key your "daily" reset on GetUtcNow().Date instead of GetLocalNow() and this test catches it instantly — no waiting for a user five and a half time zones away to complain that their quota comes back at 5:30 in the morning.

Two honest caveats. This only works if every delay in the code path takes the provider — one naked Task.Delay(5000) buried in a helper and your test is back to sleeping for real, with no error to tell you why. And I don't inject TimeProvider religiously: code that just stamps a log line can keep DateTime.UtcNow. My rule is that the moment logic branches on time or sleeps on it, the clock is a dependency and should come in through the front door.

Full runnable sample, deadlock explanation included: https://github.com/ssukhpinder/dev-to-code-samples/tree/main/013-timeprovider-fake-time

Grep your test folder for Task.Delay and Thread.Sleep and tell me the damage in the comments — I'll go first: mine was seven seconds for one class.

— still deadlocking things nobody asked me to

19 Requests Through a 10-Request Limit

Sukhpinder Singh — Thu, 30 Jul 2026 07:15:24 +0000

I shipped a rate limiter recently and told the team the endpoint was now capped at 10 requests per 10 seconds. Later I watched a burst test land 19 requests in about a second and a half. All 200s. Nothing was broken — AddFixedWindowLimiter was doing exactly what it says on the tin. I'd just never read the tin carefully. A fixed window doesn't promise "at most 10 in any 10 seconds". It promises "at most 10 per window", and windows have edges.

If a client times its bursts to straddle one of those edges, it collects almost two windows' worth of requests at once. That's the kind of claim that's easy to nod at and easy to misjudge, so I built the smallest repro that could settle it.

Two policies, same numbers

A minimal API on .NET 10 with two policies that look interchangeable in a code review:

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

    options.AddFixedWindowLimiter("fixed", o =>
    {
        o.PermitLimit = 10;
        o.Window = TimeSpan.FromSeconds(10);
        o.QueueLimit = 0;                 // reject instantly, no queueing
    });

    options.AddSlidingWindowLimiter("sliding", o =>
    {
        o.PermitLimit = 10;
        o.Window = TimeSpan.FromSeconds(10);
        o.SegmentsPerWindow = 5;          // 5 x 2-second segments
        o.QueueLimit = 0;
    });
});

(The middleware has been in the box since .NET 7; RequireRateLimiting("fixed") pins a policy to an endpoint.)

The fixed limiter keeps one counter and zeroes it every ten seconds. The sliding limiter keeps five little counters, one per 2-second segment, and "the window" is always the last five segments. That bookkeeping difference is the entire story.

The choreography

The app attacks itself with HttpClient. Four moves:

// 1. burn the current window down to zero
// 2. poll every 200ms until a request succeeds -> that's a replenish boundary
// 3. go quiet, come back 1s BEFORE the next boundary, burst 9
// 4. step just past the boundary, burst 10 more

Move 2 matters because window boundaries follow the limiter's internal clock, which starts when the first request lazily creates it — not yours. Rather than guessing, exhaust the window once and wait for permits to come back. The flip from 429 to 200 is a boundary announcing itself, and the next one is exactly one window later. Worth noticing: a real abuser gets the same information for free. It's just status codes.

Every 200 gets timestamped, and at the end the app reports the densest 10-second span it actually got away with. Conditions: Release build, localhost, small Linux container, wall clock. Not a lab, but this experiment isn't about milliseconds. It's about counting to 19.

What actually happened

--- attacking /fixed ---
  burn phase: 10 admitted, then 429s — window is empty
  permits came back at t=10.4s — boundary located
  pre-boundary burst  at t=19.4s: 9/9 admitted
  post-boundary burst at t=20.7s: 10/10 admitted
  => /fixed: densest 10s span held 19 admitted requests (limit says 10);
     those 19 arrived within 1.31s

Nine requests an instant before the reset, ten more an instant after. The limiter never blinked, because at the moment of reset it forgets everything. 19 requests in 1.31 seconds on a policy I would've sworn meant 10 per 10 seconds — a 1.9x hole in the promise, available at every boundary, forever.

Same choreography against the sliding window:

--- attacking /sliding ---
  pre-boundary burst  at t=19.4s: 9/9 admitted
  post-boundary burst at t=20.7s: 1/10 admitted
  => /sliding: densest 10s span held 10 admitted requests (limit says 10);
     those 10 arrived within 0.01s

The pre-boundary nine sail through, and then the second burst gets exactly one request in, because the nine from 1.3 seconds ago still count against the window. There's no moment of amnesia. The densest span it ever allowed was 10. The number on the tin.

That "10 within 0.01s" line deserves a beat too: any windowed limiter will serve its entire budget instantly to a cold window. If instantaneous burst is what actually hurts you, you want a token bucket with a small bucket, which is a different post.

Do you actually care?

Sometimes no. If the limit is a coarse backstop protecting capacity — no client gets more than a thousand requests a minute against this scraper-magnet endpoint — a brief 2x at a seam is noise, and fixed windows are the cheapest thing you can deploy: one counter per partition, nothing to segment. I'd leave those alone.

Where I've changed my default is limits that are promises to people. Per-tenant fairness, paid quota tiers, anything a client could deliberately game. A "10 per 10 seconds" that admits 19 is the kind of discovery that ends up in an awkward support thread. Sliding windows cost a little more memory per partition, since the segment counters exist for every tracked client, but with five segments it's small and the promise becomes true. My rule now: fixed for backstops, sliding for promises.

One caveat before you rip out every fixed window you own: everything above is a single process. The moment you scale out, every in-memory limiter — fixed or sliding — goes approximate anyway, because each node counts alone. At that point the boundary seam is the least of your inaccuracies, and you're shopping for a distributed limiter regardless.

Full runnable sample: https://github.com/ssukhpinder/dev-to-code-samples/tree/main/012-rate-limit-window-burst — it takes about 45 seconds to run because it has to sit through real windows.

Is your fixed window a backstop or a promise? If it's a promise, I'd go check what your densest span really is — and I'd like to hear what you find in the comments.

— still stress-testing promises nobody asked me to verify

The Freeze Fee: What FrozenDictionary Charges and When It Pays

Sukhpinder Singh — Wed, 29 Jul 2026 08:12:44 +0000

There's a static lookup table in every service I've ever worked on. A thousand-ish feature flags, or route metadata, or country codes — built once at startup, read on every single request, never touched again. For years my fingers have typed ToImmutableDictionary() for those. Immutable, read-only, sounds correct. Last night I finally asked the question I should've asked in 2023: is "immutable" actually the fast option here, or did I just like the word?

So I lined up the three containers .NET gives you for a build-once, read-forever table and made each of them do ten million lookups.

The contenders

Same 1,000 feature-flag style keys (flags:checkout:variant-0042), same values, default ordinal comparer for all three. No tricks, just the three ways you'd naturally write it:

var dictionary = new Dictionary<string, string>(pairs);
var immutable  = pairs.ToImmutableDictionary();
var frozen     = pairs.ToFrozenDictionary();   // System.Collections.Frozen, .NET 8+

The lookup loop cycles through 4,096 pre-shuffled keys so the branch predictor can't memorize the sequence, and sums value lengths so the JIT can't delete the work:

long checksum = 0;
for (var i = 0; i < LookupOps; i++)
    if (frozen.TryGetValue(hitQueries[i & QueryMask], out var v))
        checksum += v.Length;

Ten million lookups per round, best of five rounds, .NET 10 Release build in a small Linux container. Not a lab — I care about the ratios, not the absolute nanoseconds.

The part that made me wince

== lookups, all keys present ==
Dictionary          :   18.0 ns/lookup
ImmutableDictionary :   86.7 ns/lookup
FrozenDictionary    :   11.9 ns/lookup

FrozenDictionary beats plain Dictionary by about 1.5x. Nice. But look at the middle line. ImmutableDictionary — the thing I've been using specifically for read-only data — is over 7x slower than frozen, and nearly 5x slower than the boring mutable Dictionary it was supposedly an upgrade from.

The wince is because this isn't a bug, it's a design I'd never bothered to understand. ImmutableDictionary isn't a read-optimized dictionary that happens to be immutable. It's a hash trie — a tree — built so that "copy this dictionary with one extra entry" is cheap and doesn't disturb the original. Every lookup walks pointers through tree nodes. You're paying, on every read, for a copy-with-changes capability my startup table will never use once.

FrozenDictionary is the opposite trade. ToFrozenDictionary() takes its time inspecting your actual keys — for strings it can find the few characters that distinguish the whole key set and hash only those — then picks a specialized internal layout for exactly that data. All the cleverness happens once, at construction. Which raises the obvious question: what does that cost?

The freeze fee

== construction, 1,000 entries, avg of 2,000 builds ==
new Dictionary(pairs)  :     21.8 µs/build
ToImmutableDictionary():    211.4 µs/build
ToFrozenDictionary()   :    166.8 µs/build

There it is. Freezing 1,000 entries costs roughly 8x building a plain Dictionary — about 145 µs of surcharge in my runs. That's the fee, and it's real: build a FrozenDictionary per request and you've made everything worse for no reason.

But here's the twist I didn't see coming: ToImmutableDictionary() costs more than the freeze. For a build-once table, ImmutableDictionary loses on both ends — more expensive to construct and 7x slower to read. There's no scenario in that use case where it's the right pick. It still has a real job — when you genuinely need cheap non-destructive updates, like versioned snapshots of a changing set — but "this data never changes" was never that job. I'd been reading "immutable" as "optimized for reading" for two years. It means "optimized for copying."

My little program also computed the break-even against Dictionary: the ~145 µs surcharge divided by the ~6 ns saved per hit comes out to roughly 24,000 lookups. A singleton flag table consulted a few times per request clears that in the first minute of traffic, then collects the discount forever.

Where the win shrinks

Honesty section. Lookups for keys that don't exist barely moved: 14.0 ns for Dictionary vs 11.8 ns frozen. Dictionary already rejects most misses on a hash mismatch without ever comparing strings, so there's less waste for frozen to reclaim. I expected miss-heavy workloads to be the showcase and they're the weakest result on the table. If your table mostly answers "no", the upgrade is real but small.

And the usual caveats: these are my ratios on one container with 1,000 string keys. Different key shapes get different specialized strategies, tiny tables are fast in anything, and none of this matters on a dictionary you rebuild often — per-request construction hands the 8x fee back with interest.

My rule after this experiment, stated as the opinion it is: any static readonly Dictionary that nothing ever writes to is a FrozenDictionary wearing the wrong coat. And any ToImmutableDictionary() on data that never changes is a bug report I'm filing against my own muscle memory.

Full runnable sample: https://github.com/ssukhpinder/dev-to-code-samples/tree/main/011-frozen-dictionary-lookup

Got a ToImmutableDictionary() sitting on startup data somewhere? Go time it — and tell me in the comments if your ratio beats my 7x.

— still benchmarking things nobody asked me to, and serving the results cold

The 400 I Didn't Have to Write

Sukhpinder Singh — Wed, 29 Jul 2026 07:12:10 +0000

Every POST handler I've written in a minimal API for the last four years opens with the same liturgy: null-check the name, range-check the price, build a dictionary of errors, bail with a 400. Controllers got automatic model validation back when [ApiController] shipped, and then minimal APIs arrived without it and we all quietly went back to writing if-blocks like it was 2010. I counted the validation preamble in the demo handler I wrote for this post: eleven lines before the first line of actual work.

.NET 10 finally closes that gap, and it's one line. I spent an afternoon poking at it, and the most interesting thing I found wasn't the feature working. It was my own validation code silently becoming unreachable.

The before picture

Here's the handler shape I mean. One DTO, three rules, all enforced by hand:

app.MapPost("/manual/products", (CreateProduct dto) =>
{
    var errors = new Dictionary<string, string[]>();
    if (string.IsNullOrWhiteSpace(dto.Name))
        errors["Name"] = ["Name is required."];
    else if (dto.Name.Length > 80)
        errors["Name"] = ["Name must be 80 characters or fewer."];
    if (dto.Price is < 0.01m or > 10_000m)
        errors["Price"] = ["Price must be between 0.01 and 10000."];
    if (dto.SalePrice is { } sale && sale >= dto.Price)
        errors["SalePrice"] = ["SalePrice must be lower than Price."];
    if (errors.Count > 0)
        return Results.ValidationProblem(errors);

    return Results.Created($"/products/1", dto);
});

It works. It also gets copy-pasted into every endpoint that binds a body, drifts a little each time, and keeps the rules as far away from the type as possible. The DTO says nothing about what a valid product is; the truth lives in some handler.

One line and a record

The .NET 10 version. Rules move onto the type as plain DataAnnotations:

builder.Services.AddValidation();

app.MapPost("/products", (CreateProduct dto) =>
    Results.Created($"/products/1", dto));

public record CreateProduct(
    [property: Required, StringLength(80)] string Name,
    [property: Range(0.01, 10_000)] decimal Price,
    decimal? SalePrice);

No package reference — it's in the shared framework. I didn't register CreateProduct anywhere either; binding a parameter of that type is enough. My demo app probes itself with HttpClient (this is behavior, not benchmarks — .NET 10 in a small Linux container), and here's the real exchange when I feed it garbage:

POST /products         [garbage in: {"name":"","price":-5,"salePrice":3}]
  -> 400 BadRequest
  {"title":"One or more validation errors occurred.","errors":{"Name":["The Name field is required."],"Price":["The field Price must be between 0.01 and 10000."]}}

The handler never ran. Validation happens at binding time, before your code, and the response is the same ValidationProblemDetails shape controllers produce, so clients can't tell which flavor of endpoint rejected them. Query parameters get the same treatment — an attribute directly on the parameter is enough:

app.MapGet("/search", ([Range(1, 100)] int pageSize = 20) =>
    Results.Ok(new { pageSize }));

GET  /search?pageSize=0
  -> 400 BadRequest
  {"errors":{"pageSize":["The field pageSize must be between 1 and 100."]}}

The part that surprised me

First version of my demo kept the manual endpoint exactly as written above, so I could compare the two worlds side by side. Then I ran it, sent the garbage payload to the manual endpoint, and got back error messages I never wrote: "The Name field is required." That's the framework's wording, not mine.

Because the DTO now carries attributes, AddValidation was rejecting the request before my eleven lines ever executed. My checks weren't wrong. They were dead. If your codebase already has attributes on DTOs from an earlier FluentValidation-plus-annotations era, turning this on may start enforcing rules you forgot were declared. To make the manual endpoint behave like the old world for the demo, I had to opt it out explicitly:

app.MapPost("/legacy/products", (CreateProduct dto) => ...)
    .DisableValidation();

And the receipt, from the same run:

POST /legacy/products  [garbage in, validation off]
  -> 201 Created
  {"name":"","price":-5,"salePrice":3}

A product with no name and a price of minus five, welcomed into the system. That's the world we're leaving behind.

Cross-field rules work through the IValidatableObject you already know: my SalePrice < Price rule lives there, and an invalid pair comes back as a clean 400. One nuance the run exposed: my manual endpoint reported all three errors at once, but the framework reported only the two attribute failures — Validate doesn't run until attribute validation passes, so cross-field errors arrive in a second wave. Users fix the name and the price, resubmit, and only then learn the sale price is wrong. Mildly annoying, worth knowing.

Where I'd still say no

If your rules are genuinely conditional — this field is required only for that tenant, prices validate against a table in the database — attributes will fight you, and FluentValidation still earns its keep. The stock messages are also flatly English; there are hooks for customizing, but if you need localized error text today, check that story before migrating anything user-facing. And this is minimal-API binding only. Controllers already had it, so there's nothing to migrate there.

My opinion, stated as one: for the boring 80% of validation — required, range, length, email — attributes on the type beat checks in the handler, because the contract travels with the DTO instead of hiding in endpoint code. This should have shipped in .NET 6. I'll take it in 10.

Full runnable sample: https://github.com/ssukhpinder/dev-to-code-samples/tree/main/010-minimal-api-validation

Are you moving these checks onto attributes, or does FluentValidation own your validation layer for good reasons I've skipped? Tell me in the comments.

— still deleting code nobody asked me to.