DEV Community: Anaya Upadhyay

SOLID in real .NET: the S and D that actually change your code

Anaya Upadhyay — Fri, 24 Jul 2026 06:15:00 +0000

Last Monday someone on my feed changed an invoice email template and watched the tax calculation tests fail. Six red tests, none of them about email. If that sequence sounds impossible, you have not met InvoiceService yet.

SOLID usually gets taught as five poster definitions, recited once for the interview and never opened again. In day-to-day .NET work, though, two of the letters do almost all of the refactoring: the S and the D. This is the working version of both, with the before and after in full, targeting .NET 10.

S is "one reason to change," not "one thing to do"

The Single Responsibility Principle is Robert C. Martin's, and his formulation is precise: a class should have one reason to change. The popular paraphrase, "a class should do one thing," is the version that misleads people, because "one thing" is whatever granularity you feel like defending in review. "This class handles invoices" sounds like one thing. It is not.

Count reasons to change instead. Better yet, count the people who can demand a change:

public class InvoiceService
{
    // finance changes this one
    public decimal CalculateTax(Invoice invoice)
    {
        var rate = invoice.Category == ProductCategory.Reduced ? 0.05m : 0.13m;
        return Math.Round(invoice.Subtotal * rate, 2);
    }

    // design changes this one
    public byte[] RenderPdf(Invoice invoice)
    {
        using var doc = new PdfDocument();
        doc.AddHeader(invoice.Number);
        doc.AddTotals(invoice.Subtotal, CalculateTax(invoice));
        return doc.ToBytes();
    }

    // marketing changes this one
    public async Task SendEmailAsync(Invoice invoice)
    {
        var body = EmailTemplates.Render("invoice-ready", invoice);
        await _mailer.SendAsync(invoice.CustomerEmail, body);
    }
}

Three stakeholders, one file. Every edit for any of them re-opens code the other two depend on, which is how a template tweak lands in the tax test report. The class compiles, passes review, and quietly taxes every future change with a full regression run.

The split is not clever. That is the point:

public class TaxCalculator
{
    public decimal Calculate(Invoice invoice)
    {
        var rate = invoice.Category == ProductCategory.Reduced ? 0.05m : 0.13m;
        return Math.Round(invoice.Subtotal * rate, 2);
    }
}

public class InvoicePdfRenderer
{
    public byte[] Render(Invoice invoice, decimal tax)
    {
        using var doc = new PdfDocument();
        doc.AddHeader(invoice.Number);
        doc.AddTotals(invoice.Subtotal, tax);
        return doc.ToBytes();
    }
}

public class InvoiceMailer(IMailer mailer)
{
    public Task SendAsync(Invoice invoice)
    {
        var body = EmailTemplates.Render("invoice-ready", invoice);
        return mailer.SendAsync(invoice.CustomerEmail, body);
    }
}

Now the email template edit touches InvoiceMailer, its tests, and nothing else. The blast radius of a change drops to one file, and the diff a reviewer reads matches the requirement that caused it. Reviewers notice that. So does whoever gets paged.

One honest caveat: you can over-split. If two pieces of code change for the same reason at the same time, separating them is ceremony, not architecture. The stakeholder count is the test, in both directions.

D is about who owns the concrete type

The Dependency Inversion Principle, also Martin's, says high-level policy should not depend on low-level detail; both should depend on abstractions. In C# terms it is more blunt: your business rule should not new up the infrastructure it talks to.

Here is the weld:

public class OrderService
{
    public async Task PlaceAsync(Order order)
    {
        // the high-level rule owns a wire-level detail
        var mailer = new SmtpMailer("smtp.internal");
        await mailer.SendAsync(order.Receipt());
    }
}

Why this is wrong, concretely and not philosophically:

The order rule is welded to SMTP. Moving to SendGrid, or to a queue, means editing checkout logic that has nothing to do with either.
It cannot be tested in isolation. Run this test suite and a real mail server answers, or the test fails for network reasons your logic does not have.
The dependency is invisible. Nothing in the constructor tells a reader that placing an order sends mail.

The fix is constructor injection with the concrete type owned by the composition root:

// the abstraction the rule depends on
public interface IMailer
{
    Task SendAsync(string to, string body);
}

// C# 12 primary constructor, current on .NET 10
public class OrderService(IMailer mailer)
{
    public async Task PlaceAsync(Order order)
    {
        // rule stays pure; delivery is a detail
        await mailer.SendAsync(order.CustomerEmail, order.Receipt());
    }
}

// Program.cs, the one place that knows the concrete type
builder.Services.AddScoped<IMailer, SmtpMailer>();
builder.Services.AddScoped<OrderService>();

Swap SMTP for SendGrid and the diff is one registration line. Test the order rule and the fake is three lines. The constructor now tells the truth about what the class needs, which is the property everything else hangs off.

A registration note, since it comes up: AddScoped gives you one instance per request in ASP.NET Core, which is the safe default for anything holding request-shaped state. A stateless mailer could be a singleton. What matters for the principle is where the concrete type lives, not which lifetime you pick, and lifetimes deserve their own article anyway.

Why S and D need each other

Split a class without inverting its dependencies and you own small classes you still cannot fake in a test. Invert dependencies on a class with five responsibilities and you get a constructor with nine parameters shouting at you, which is at least useful information.

Do both and every seam becomes two things at once: a swap point and a test point. TaxCalculator behind ITaxCalculator can be replaced the day tax rules move to a rules engine, and faked the day you want a checkout test that does not care about VAT. The S made the seam small enough to be honest; the D made it loose enough to be useful.

This is also where Open/Closed quietly shows up for free. Once the rule depends on IMailer, extending behavior means writing a new implementation rather than editing a working one. You did not set out to satisfy O. It fell out.

The other three, honestly

Liskov Substitution earns its keep in inheritance-heavy trees, and modern .NET leans composition hard enough that many teams meet L rarely, mostly in older code. Interface Segregation is S applied to interfaces: if a fake has to implement six members to test one, the interface is hoarding. Fine principles, both. They just drive fewer of the refactors you will actually perform this quarter, which is why this article gave them a paragraph and gave S and D the code.

The pre-PR checklist

One reason to change per class. Count stakeholders, not methods.
No new for anything you would ever swap or fake in a test.
The constructor names every dependency. Injecting IServiceProvider is a service locator wearing a lanyard, and it moves failures to runtime.
Interfaces stay small. A six-member fake for a one-member test is a smell.
Concrete types live in Program.cs registrations, nowhere else.

Version note: the samples above use C# 12 primary constructors and target .NET 10, the current LTS. Everything conceptual applies to any supported .NET version; only the constructor syntax is version-flavored, and the classic constructor form works identically.

If you prefer this material as a visual walkthrough, the 9-slide breakdown of this exact refactor lives at @thesharpfuture, where a new one lands every week.

JWT Auth in .NET 8: The Validation Settings People Skip

Anaya Upadhyay — Fri, 10 Jul 2026 06:15:00 +0000

There is a category of security bug that produces no error, no log entry, and no failing test. A token that should have been rejected gets a 200 instead, and the only way anyone finds out is by reading the auth configuration line by line, usually after something has already gone wrong.

Most of these live inside one class: TokenValidationParameters. Its defaults are good. The trouble is that its defaults are also easy to turn off, and the moments when people turn them off tend to be the moments they are trying to make an error message go away.

This article walks the five settings that get skipped most, what each one actually checks, what turning it off silently allows, and what the correct .NET 8 configuration looks like. At the end there is a checklist you can run against your own codebase in about two minutes.

The baseline

Here is a complete, correct JWT bearer setup for a .NET 8 minimal API. Everything below refers back to this.

using System.Text;
using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.IdentityModel.Tokens;

var builder = WebApplication.CreateBuilder(args);

builder.Services
    .AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(options =>
    {
        options.TokenValidationParameters = new TokenValidationParameters
        {
            ValidateIssuer = true,
            ValidIssuer = "https://auth.example.com",

            ValidateAudience = true,
            ValidAudience = "orders-api",

            ValidateLifetime = true,
            ClockSkew = TimeSpan.FromMinutes(1),
            RequireExpirationTime = true,

            ValidateIssuerSigningKey = true,
            IssuerSigningKey = new SymmetricSecurityKey(
                Encoding.UTF8.GetBytes(builder.Configuration["Jwt:Key"]!))
        };
    });

builder.Services.AddAuthorization();

var app = builder.Build();

app.UseAuthentication();
app.UseAuthorization();

app.MapGet("/orders", () => Results.Ok(new[] { "order-1", "order-2" }))
   .RequireAuthorization();

app.Run();

One note before the flags: if you point the handler at an identity provider via options.Authority, the issuer and signing keys come from OIDC discovery metadata and much of this configures itself. The bugs below live almost entirely in hand-rolled setups, which is exactly where copied snippets end up.

1. ValidateLifetime

Default: true. Lifetime validation checks the token's nbf (not before) and exp (expires) claims against the current UTC time.

The bug is not the default. The bug is this line, which shows up in copied configuration with remarkable consistency:

ValidateLifetime = false

It usually gets added to silence a lifetime validation error during local testing, often when someone's test token has expired and regenerating it feels like friction. The error goes away. The line stays. It ships.

From that point on, an expired token validates. The signature still checks out, so nothing looks wrong from the outside: the request carries a structurally valid, correctly signed token whose expiry date has simply stopped mattering. Picture a leaked token from six months ago. Your API would still honor it.

The fix is deletion. The default is already true, so the safest version of this configuration is the one with less code in it. If a flag has to be false for a test to pass, that belongs in the test project's configuration, not in Program.cs.

2. ClockSkew

Default: five minutes. TokenValidationParameters.DefaultClockSkew is TimeSpan.FromMinutes(5) in the Microsoft.IdentityModel reference documentation, and it applies as tolerance on both ends of the lifetime check: a token is accepted when nbf - skew <= now <= exp + skew.

This one is not a flag someone flipped. It is a default nobody tuned, and it means every token in your system is accepted for five minutes past its printed expiry.

For hour-long tokens, that grace window is noise. For short-lived access tokens the math changes: picture a five minute access token, which now validates for close to ten. Whatever reasoning went into choosing that five minute lifetime, the effective lifetime is quietly double it.

ClockSkew = TimeSpan.FromMinutes(1)

The temptation is to set it to TimeSpan.Zero, and some teams do. Before you follow them, remember what the skew is for: real machines drift, and a token minted by an identity server whose clock runs twenty seconds ahead of yours would be rejected as "not yet valid" with zero tolerance. Size the skew to your infrastructure and your token lifetime rather than deleting it on principle.

3. ValidateIssuer

Default: true. Issuer validation checks the token's iss claim against ValidIssuer or ValidIssuers.

Here is how it gets disabled in the wild. Someone wires up validation, runs the app, and gets an IDX10204 or IDX10205 error from the issuer check, typically because ValidIssuer was never set or does not match what the identity server actually mints. The fastest way to make that exception disappear is:

ValidateIssuer = false

And it does disappear. Along with the question "who minted this token?"

With issuer validation off, a token signed with any key your API accepts will pass, regardless of where it came from. In a system with one API and one symmetric key that may sound theoretical. In a system where keys get shared across environments, or where a staging identity server signs with the same key as production, it stops being theoretical fast.

The exception was the security feature. Fix the configuration instead of the symptom:

ValidateIssuer = true,
ValidIssuer = "https://auth.example.com"

4. ValidateAudience

Default: true. Audience validation checks the token's aud claim against ValidAudience or ValidAudiences, answering the question "was this token minted for me, specifically?"

Same disable story as the issuer, different error code: an IDX10208 or IDX10214 fires because no audience was configured, and ValidateAudience = false makes it stop. What it also does is make every API in your system interchangeable from a token's point of view.

Picture two services, billing-api and orders-api, validating with the same signing key. A token minted for billing carries aud: "billing-api". With audience validation off, orders accepts it too. One leaked or over-scoped token now opens both doors, and any future service that joins the key club gets opened by it as well.

ValidateAudience = true,
ValidAudience = "orders-api"

One audience per API. The scope of a token should mean something.

5. RequireExpirationTime

Default: true. This is the flag behind the lifetime flag, and it covers a case most people have not considered: what happens when a token has no exp claim at all?

Lifetime validation checks the expiry when one is present. RequireExpirationTime is what makes its presence mandatory. Set it to false and a token minted without an expiry sails through lifetime validation, because there is nothing to evaluate. That token has no end date. It outlives the incident review, the key rotation discussion, and possibly the service itself.

There is close to no legitimate reason for an access token without an expiry, so this default deserves to stay exactly where it is:

RequireExpirationTime = true

Two more worth knowing

RequireSignedTokens defaults to true and rejects unsigned tokens. Leave it. An API that accepts alg: none tokens is an API with optional authentication.

ValidateIssuerSigningKey defaults to false, and this one surprises people in the other direction: signatures are verified regardless. What this flag adds is validation of the key material itself, for example rejecting a token signed with an X.509 certificate that has expired. Worth turning on when your signing keys are certificates with real lifetimes.

Why the flags don't cover for each other

Validation is a chain of independent gates: signature, issuer, audience, lifetime. Each one answers a different question. Signature asks whether the token is intact. Issuer asks who minted it. Audience asks whether it was minted for you. Lifetime asks whether it is still alive.

A yes to one answers none of the others, which is why "the signature checks out" is such a dangerous form of reassurance. Disable a gate and it is not weakened, it is gone, and the three remaining gates will keep passing tokens that the fourth would have stopped. No exception fires when a check is skipped. Skipped checks are silent by definition.

The checklist

Run this against every TokenValidationParameters in your codebase:

ValidateLifetime stays true. Delete the override rather than negotiating with it.
ClockSkew sized to your token lifetime, not left at the five minute default for short-lived tokens.
ValidIssuer named. Tokens from anywhere are not a feature.
ValidAudience set per API. One token, one door.
RequireExpirationTime stays true. Every token gets an end date.
Bonus: RequireSignedTokens untouched, ValidateIssuerSigningKey considered if your keys are certificates. Then the two minute audit: grep your solution for = false inside any TokenValidationParameters initializer and make each hit justify itself with a comment naming who approved it and why. In my experience most of them can't.

If you prefer this material as visual breakdowns, I publish them as carousels and short reels at @thesharpfuture on Instagram, aimed at junior to mid-level .NET developers. This week's set covers exactly these five flags.

Found one of these switched off in a real codebase? I'd genuinely like to hear which one, and what the comment next to it said, if there was one.

Minimal API vs Controllers in ASP.NET Core: When Each One Actually Wins

Anaya Upadhyay — Fri, 12 Jun 2026 06:15:00 +0000

Somewhere around .NET 6, the Minimal API question stopped being academic. Teams actually started shipping with it. And then some of those teams quietly started adding Controllers back six months later.

Both choices can be correct. The problem is that the wrong framing "which one is simpler?" or "which one is more modern?" lands you in the wrong answer. Here is the framing that works.

The real question

Both Minimal API and Controllers ship working APIs. What they optimize for is completely different, and ignoring that difference is how you end up refactoring.

Start with three questions:

How complex is your routing logic?
A handful of endpoints vs. a full domain model with dozens of grouped resources. That gap matters.

Do you need the full action filter pipeline?
Controller action filters and DI-bound per-action behavior make unit testing dramatically easier at scale. Minimal API has endpoint filters, they work, but they are not the same abstraction.

Who else touches this codebase?
Controllers have 15 years of conventions. A developer who has never seen your project knows where to look. Minimal API is learnable fast, but it is not pre-loaded.

When Minimal API wins

Microservices with a narrow surface area

One service. A handful of well-defined endpoints. You do not need to carry the full MVC stack for a payment webhook receiver or an internal reporting service. MapGet, MapPost, done.

Internal tooling and prototypes

You want working code in minutes. Controllers impose ceremony that has no return on a one-team service nobody else integrates with. The shorter the expected lifespan, the higher the ceremony cost.

HTTP-native patterns

Webhooks, health checks, simple CRUD. Request in, response out. The Minimal API pipeline maps directly to those problems. No inheritance, no attributes, no discovery conventions.

Small teams that own the full stack

When the team is small and the scope is bounded, conventions are mostly overhead. Minimal API gives that team agency over their own structure without fighting a framework.

What a clean Minimal API endpoint looks like

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

// GET /products/{id}
app.MapGet("/products/{id}",
    async (int id, IProductRepository repo) =>
{
    var product = await repo.GetByIdAsync(id);
    return product is null
        ? Results.NotFound()
        : Results.Ok(product);
});

app.Run();

The whole thing fits. DI works. IProductRepository is resolved from the container automatically. Results helpers cover the common response patterns without IActionResult boilerplate.

When Controllers win

Large domain with many grouped resources

ProductsController, OrdersController, UsersController. Controllers namespace your API implicitly and make routing intentions explicit without attribute gymnastics. At 40+ endpoints the ergonomics flip decisively.

Action filters are doing real work

Audit logging, model validation attributes, custom authorization policies scoped per action. The filter pipeline on Controllers is composable in ways that Minimal API endpoint filters currently are not. If your cross-cutting concerns are complex, go where they fit cleanly.

Multiple developers sharing the codebase

This one is underrated. Controllers have 15 years of conventions behind them. A new developer knows where to look without asking anyone. That knowledge is worth something, especially as the team grows.

Versioned APIs with complex binding

Route groups help in Minimal API, but versioned controllers with [ApiVersion] and strongly-typed model binding still carry less ceremony in practice. If you are versioning three major API versions in production, Controllers are the path of least resistance.

The same endpoint as a Controller

[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    private readonly IProductRepository _repo;

    public ProductsController(IProductRepository repo)
        => _repo = repo;

    // GET api/products/{id}
    [HttpGet("{id}")]
    public async Task<IActionResult> GetById(int id)
    {
        var product = await _repo.GetByIdAsync(id);
        return product is null
            ? NotFound()
            : Ok(product);
    }
}

More structure. More surface area. Worth it when that structure is carrying load.

The side-by-side

Dimension	Minimal API	Controllers
Boilerplate	Minimal	Moderate
Testability	Good with DI	Excellent
Action filters	Endpoint filters only	Full filter pipeline
Routing	Lambda, explicit	Attribute + convention
Team ramp-up	Fast for new .NET devs	Familiar to most devs
Scale target	Micro to mid	Mid to large domain
Swagger / OAS	Full support	Full support

Neither row is a clear winner on every dimension. That is the point.

The hybrid pattern. You do not always have to pick

This is the one that most people miss. You can use both in one solution:

// Program.cs
var app = builder.Build();

// Minimal API: health + lightweight probes
app.MapGet("/health", () => Results.Ok());
app.MapGet("/version", () => AppInfo.Version);

// Controllers: complex domain resources
app.MapControllers();

app.Run();

MapControllers() and MapGet() compose cleanly. Route groups and controller routing do not conflict. Use Minimal API for the surface area where it fits, Controllers where the domain needs structure.

This is not a workaround. It is a supported, intended usage pattern.

The decision checklist

Save this for the next project kickoff:

New microservice or internal tool → Minimal API
Existing codebase already on Controllers → Controllers
Need action filter pipeline → Controllers
Prototyping or validating an idea → Minimal API
Large domain, many grouped routes → Controllers
Mixed concerns in one solution → Hybrid

What actually goes wrong

The most common failure mode is not choosing the wrong approach. It is choosing one approach and never questioning it as the project grows. A project that starts as a three-endpoint Minimal API and quietly becomes a 60-endpoint domain model has a debt problem.

Pay attention to the signals:

Duplicated per-endpoint middleware logic → Controllers
Handler functions growing past 30 lines → consider Controllers
Difficulty testing endpoints in isolation → Controllers
Ceremony cost outweighing value → reconsider Minimal API The framework does not enforce a migration path. You have to notice it yourself.

The full carousel version of this breakdown (with code examples for each scenario) is on Instagram at @thesharpfuture.

Log Aggregation in .NET 8: Seq vs ELK vs Loki

Anaya Upadhyay — Tue, 26 May 2026 09:15:00 +0000

I have seen the same setup at more companies than I can count: every service writing logs to stdout, a few rotating files scattered across VMs, maybe one service sending to Application Insights, and nobody quite sure where the logs from the background jobs go.

It works fine until something breaks in production. Then you have an error, four services, and zero way to trace a single request across any of them.

That is the problem log aggregation solves. This article covers what it actually means in a .NET 8 stack, how to set it up with Serilog, and how to pick the right aggregator for where your team is right now.

What log aggregation actually means

The idea is simple: every service in your system writes structured log events to a central store, and you query that store instead of grepping files.

The pipeline has three parts:

Your app - calls ILogger<T> with structured message templates
A sink - Serilog serializes and ships the event to a destination
An aggregator - receives, indexes, and stores the events so you can query them by any property

The key word is structured. If your log messages are plain strings, you have traded one grep problem for another. The entire value of aggregation comes from being able to filter on OrderId, CorrelationId, CustomerId, or any other property you attached to the event.

Setting up Serilog with multiple sinks

Sinks are composable. You can write to Seq locally, Elasticsearch in production, and a rolling file as a fallback, all from the same configuration.

// Program.cs
Log.Logger = new LoggerConfiguration()
    .Enrich.WithCorrelationId()
    .MinimumLevel.Override("Microsoft", LogEventLevel.Warning)
    .MinimumLevel.Override("System", LogEventLevel.Warning)
    .WriteTo.Seq("http://localhost:5341")
    .WriteTo.Elasticsearch(opts =>
    {
        opts.IndexFormat = "logs-{0:yyyy.MM}";
        opts.AutoRegisterTemplate = true;
    })
    .WriteTo.File("logs/app-.log", rollingInterval: RollingInterval.Day)
    .CreateLogger();

builder.Host.UseSerilog();

A few things worth noting here. The MinimumLevel.Override calls are important in production. Without them, Microsoft framework internals log at Debug and they will flood your aggregator with noise that buries your actual signals. Set them to Warning in production environments.

The Enrich.WithCorrelationId() call requires the Serilog.Enrichers.CorrelationId package. Pair it with a middleware that sets BeginScope on every request and every log line inside that request will carry the same correlation ID. Without it, log aggregation gives you a better filing cabinet but not a better answer.

Seq: start here

If your team is not running a local aggregator today, start with Seq. It is free for individual use, has first-class support for structured .NET logs, and takes about two minutes to set up.

docker run --rm -e ACCEPT_EULA=Y -p 5341:5341 -p 80:80 datalust/seq:latest

Then in appsettings.Development.json:

"Serilog": {
  "WriteTo": [{
    "Name": "Seq",
    "Args": { "serverUrl": "http://localhost:5341" }
  }]
}

Open http://localhost and you will see every structured event your application emits. Filter by @Level = 'Error', or OrderId = '123', or CorrelationId = 'abc' - all of it works immediately because the properties are indexed, not buried inside a string.

The query experience alone is worth it for local development. You stop reading raw console output and start asking questions.

Picking a production aggregator

Here is a direct comparison of the three options most .NET teams evaluate.

Seq

Good for teams up to maybe 20 engineers with moderate log volume. The single-node architecture is a real ceiling but it is not a problem until it is a problem. Reasonably priced for small teams and the operational overhead is low. If you are a startup or a small product team, Seq in production is a completely legitimate choice.

ELK Stack (Elasticsearch, Logstash, Kibana)

The right choice when you have high volume, need full-text search across log content, or have an ops team that can own the infrastructure. Kibana dashboards are genuinely good for sharing observability across engineering and operations. The tradeoff is real though: you are running three services, Elasticsearch is resource-hungry, and the licensing situation has changed a few times in recent years - worth reviewing before you commit. Not a good first production choice for a small team.

Grafana Loki

Loki takes a different approach. Instead of indexing the full content of every log line, it indexes labels only. This makes it significantly cheaper at scale. The tradeoff is that you cannot do full-text search across log content by default - you query by labels and then filter within results.

If your team is already running Grafana and Prometheus, Loki is the natural addition. It integrates tightly with both and keeps your observability stack in one place. On Kubernetes it scales well horizontally. The LogQL query language takes getting used to, but it is not complex.

The three mistakes that break aggregation in production

String concatenation in message templates. The moment you write _logger.LogInformation("Order " + id + " placed"), the structured property is gone. The aggregator receives a plain string. You cannot filter on OrderId in Seq or Kibana because it does not exist as a property. Always use message templates: _logger.LogInformation("Order {OrderId} placed", id).

Console.WriteLine anywhere in your codebase. It bypasses every sink. It is unstructured, and in a containerised environment it is lost on restart. Any Console.WriteLine in application code should be replaced with ILogger. This includes library code you own.

No minimum level override per environment. Framework-level components log a lot at Debug. In production, shipping those events to your aggregator wastes storage and makes real errors harder to find. A MinimumLevel.Override for Microsoft.* and System.* set to Warning is one configuration line that keeps your signal-to-noise ratio sane.

Before you configure anything

The aggregator is the last decision, not the first.

Get structured message templates right across your codebase. Set up a correlation ID scope in middleware so every log line in a request shares an ID. Pick the minimum level that makes sense for each environment.

Once those are in place, the aggregator almost does not matter. Seq, ELK, Loki - they are all just different query UIs sitting on top of the structured events your app already emits correctly.

This article is part of Logging in .NET - Series 2. The full carousel version with sink configuration code and a setup checklist is on Instagram at @thesharpfuture.