Minimal APIs have always been about simplicity but validation has been one of the pain points… until now.

With .NET 10, Microsoft introduces native request validation for Minimal APIs, eliminating the need for repetitive checks and bringing them closer to the robustness of traditional controllers.

Let’s break down what’s new, why it matters, and how to use it in real-world code.

What’s New in .NET 10?

In previous versions, validation in Minimal APIs required manual checks like:

if (!MiniValidator.TryValidate(model, out var errors))
{
    return Results.ValidationProblem(errors);
}

Or using external libraries.

👉 In .NET 10, validation is now:

• Built into the framework

• Automatically executed before your endpoint logic

• Based on standard Data Annotations

• Returning consistent error responses

Step 1: Enable Validation

You only need one line to activate validation globally:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddValidation(); // New in .NET 10

var app = builder.Build();

That’s it. No filters. No middleware. No manual wiring.

Step 2: Define Your Request Model

Use familiar Data Annotations:

using System.ComponentModel.DataAnnotations;

public record CreateProductRequest(
    [Required] string Name,
    
    [Range(1, 10)] decimal Price,
    
    [Required] string Category
);

Supported annotations include:

• [Required]
  

• [Range]
  

• [MinLength]
  

• [MaxLength]
  

• [EmailAddress]
  

• and more...
  

Step 3: Create a Minimal API Endpoint

Now define your endpoint as usual:

app.MapPost(”/products”, (CreateProductRequest request) =>
{
    // This runs ONLY if validation passes
    return Results.Ok(new
    {
        Message = “Product created successfully”,
        Data = request
    });
});

No validation logic required. Clean and focused.

What Happens on Invalid Requests?

If validation fails, ASP.NET Core automatically returns a standardized response:

Example Request:

{
  “name”: “Laptop”,
  “price”: 50,
  “category”: “”
}

Response:

{
  “title”: “One or more validation errors occurred.”,
  “errors”: {
    “Price”: [
      “The field Price must be between 1 and 10.”
    ],
    “Category”: [
      “The Category field is required.”
    ]
  }
}

👉 Your endpoint is never executed.

Full Working Example

Here’s a complete Program.cs:

using System.ComponentModel.DataAnnotations;

var builder = WebApplication.CreateBuilder(args);

// Enable validation
builder.Services.AddValidation();

var app = builder.Build();

// Request model
public record CreateProductRequest(
    [Required] string Name,
    [Range(1, 10)] decimal Price,
    [Required] string Category
);

// Endpoint
app.MapPost(”/products”, (CreateProductRequest request) =>
{
    return Results.Ok(new
    {
        Message = “Product created successfully”,
        Product = request
    });
});

app.Run();

Minimal APIs vs Controllers

For a long time, controllers had a clear advantage: built-in validation.

That gap is now gone.

Automatic Validation

Before .NET 10
❌ Not available in Minimal APIs
You had to manually validate every request or use external libraries.

With .NET 10
✅ Built-in and automatic
Validation runs before your endpoint logic executes.

Clean Endpoints

Before .NET 10
⚠️ Often cluttered with validation checks
Your business logic was mixed with validation code.

With .NET 10
✅ Clean and focused
Endpoints now contain only business logic — no extra noise.

Consistency

Before .NET 10
❌ Inconsistent validation responses
Different endpoints could return different error formats.

With .NET 10
✅ Standardized responses
All validation errors follow a unified structure automatically.

Pro Tips

• Combine with FluentValidation for advanced scenarios

• Keep request models small and focused

• Use custom attributes for reusable rules

• Log validation failures for debugging insights

Final Thoughts

.NET 10 doesn’t just improve Minimal APIs —
it removes one of their biggest limitations.

You now get:

• Clean code

• Built-in validation

• Consistent behavior

• Less mental overhead

All with one line of configuration.

What Do You Think?

Have you tried this feature yet?
Do you still prefer controllers, or are Minimal APIs now your go-to?

I hope you found this guide helpful and informative.

Thanks for reading!

If you enjoyed this article, feel free to share it and follow me for more practical, developer-friendly content like this.

Most .NET developers already use GitHub for their projects.

What’s less obvious is that GitHub can also help you manage dependency security with almost no effort. If you’re using NuGet packages—and you probably are—this matters more than you think.

A single vulnerable dependency is enough to expose your entire application. And in many cases, you won’t even realize it’s there.

The good news is that GitHub provides a built-in solution: Dependabot.

The Problem with NuGet Dependencies

Adding a package is simple:

dotnet add package System.Data.SqlClient --version 4.8.4

The application builds. Everything works as expected.

But there’s a hidden risk. That version might already have a known vulnerability (a CVE). Unless you actively check, you won’t know. And by the time it’s discovered, it could already be in production.

This is a common pattern:

• Packages become outdated quietly
  

• Vulnerabilities are disclosed later
  

• Applications continue running with known risks
  

Dependency issues are rarely obvious during development, which is what makes them dangerous.

What Dependabot Actually Does

Dependabot is GitHub’s built-in dependency monitoring tool. Once enabled, it works in the background and takes care of several things automatically:

• Scans your project dependencies
  

• Detects known vulnerabilities
  

• Notifies you through security alerts
  

• Creates pull requests with safe updates
  

It’s not a replacement for good security practices, but it removes a lot of the manual work.

Step 1: Enable Dependabot

In your GitHub repository, go to:

Settings → Security → Code security and analysis

Enable the following:

• Dependency graph
  

• Dependabot alerts
  

• Dependabot security updates
  

Once these are turned on, GitHub starts analyzing your dependencies automatically.

Step 2: Let GitHub Do the Scanning

After enabling these features, GitHub will scan your .csproj files and identify vulnerable packages.

If a vulnerability is found, you’ll see an alert like this:

System.Data.SqlClient 4.8.4 → High severity vulnerability

You don’t need to run any tools manually. The scanning happens continuously in the background.

Step 3: Configure Automatic Updates

To make Dependabot proactive, add a configuration file to your repository:

.github/dependabot.yml

Example:

version: 2
updates:
  - package-ecosystem: “nuget”
    directory: “/”
    schedule:
      interval: “daily”

This tells GitHub to check for dependency updates every day.

Step 4: How Dependabot Fixes Issues

When a vulnerability is detected and a fix is available, Dependabot will open a pull request automatically.

A typical PR looks like this:

Title:

Bump System.Data.SqlClient from 4.8.4 to 4.8.5

Description:

Fixes CVE-2024-0056

This update resolves a high severity vulnerability.

At this point, the process is straightforward. You review the change, run your tests, and merge.

Step 5: Optional Local Verification

If you want to double-check locally, you can still run:

dotnet list package --vulnerable

This is useful during development, but once Dependabot is enabled, it’s no longer something you need to rely on.

Good Practices to Follow

Dependabot works best when combined with a few simple habits:

• Keep updates frequent rather than batching them
  

• Review and merge security PRs promptly
  

• Avoid packages that are no longer maintained
  

• Be aware of transitive dependencies (packages you don’t directly install)
  

These small steps significantly reduce your risk over time.

Where Tools Like Depadbot Fit

Dependabot solves the basics well: detection and automated updates.

Tools like Depadbot build on top of that by providing deeper analysis, better visibility into dependency chains, and more context around risk.

If Dependabot helps you react to vulnerabilities, tools like Depadbot help you understand and prioritize them.

Final Thoughts

Dependency security doesn’t need to be complicated.

You don’t need a full security pipeline to get started. Enabling Dependabot takes a few minutes, and from that point on, your repository is continuously monitored.

It’s a small change, but it closes a gap that many teams overlook.

One thing to remember

If Dependabot isn’t enabled, your dependencies are aging silently and you probably won’t notice until it’s too late.

👉 Full working code available at:

🔗 https://github.com/KanaiyaKatarmal/githuazureterraform

I hope you found this guide helpful and informative.

Thanks for reading!

If you enjoyed this article, feel free to share it and follow me for more practical, developer-friendly content like this.

Most developers immediately reach for WebSockets or SignalR, but in many cases that is unnecessary.

There is a much simpler solution built directly into the browser:

Server-Sent Events (SSE).

SSE allows the server to push updates to the browser over a simple HTTP connection.

And starting with modern ASP.NET Core, SSE support is now first-class with Results.ServerSentEvents().

Let’s explore how it works.

What Are Server-Sent Events?

Server-Sent Events are a one-way streaming protocol where:

• The client opens a connection

• The server keeps the HTTP connection open

• The server continuously pushes messages

The browser receives these messages using the EventSource API.

Key characteristics:

• Built on standard HTTP

• Automatic reconnection

• Supports custom events

• Lightweight compared to WebSockets

Architecture:

Browser (EventSource)
        │
        │ HTTP GET /progress
        ▼
ASP.NET Core SSE endpoint
        │
        │ Stream events
        ▼
Browser receives messages in real time

Basic SSE Example in ASP.NET Core

Let’s build a simple job progress stream.

Server Setup

using System.Net.ServerSentEvents;

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

app.MapGet("/progress", () =>
{
    async IAsyncEnumerable<SseItem<string>> Stream()
    {
        for (int i = 1; i <= 10; i++)
        {
            yield return new SseItem<string>(
                data: $"{i} completed"
            );

            await Task.Delay(1000);
        }

        yield return new SseItem<string>(
            data: "Job Finished ✅",
            eventType: “completed”
        );
    }

    return Results.ServerSentEvents(Stream());
});

app.Run();

Key idea:

Instead of returning a normal response, we return an async stream of events.

ASP.NET Core automatically converts each item into the SSE wire format:

data: Step 1 completed

data: Step 2 completed

event: completed
data: Job Finished

Client Side: Listening to Events

Browsers support SSE through the EventSource API.

Example:

<script>
const evt = new EventSource("/progress");

// default messages
evt.onmessage = function(e) {
    console.log(e.data);
};

// custom event
evt.addEventListener("completed", function (e) {
    console.log("Job done:", e.data);
    evt.close();
});
</script>

When the server sends:

data: Step 3 completed

The browser triggers:

evt.onmessage

When the server sends:

event: completed
data: Job Finished

The browser triggers the custom event listener.

Full Working Example

Your HTML page could look like this:

<h2>Live Job Progress</h2>
<div id="log"></div>

<script>
const evt = new EventSource("/progress");

evt.onmessage = function(e) {
    document.getElementById("log").innerHTML +=
        "<p>" + e.data + "</p>";
};

evt.addEventListener("completed", function (e) {
    document.getElementById("log").innerHTML +=
        "<p><strong>" + e.data + "</strong></p>";

    evt.close();
});
</script>

The result is a live updating progress log without refreshing the page.

Why Use SSE Instead of WebSockets?

SSE shines when you only need server → client streaming.

Use SSE when you need:

• progress updates

• streaming logs

• AI token streaming

• notifications

• dashboard updates

Use WebSockets when you need two-way communication.

Advantages of SSE in ASP.NET Core

Modern ASP.NET Core makes SSE especially powerful because it integrates with:

• IAsyncEnumerable

• Minimal APIs

• Streaming responses

This means you can connect SSE directly to:

• database change streams

• background workers

• message queues

• AI token streams

Example pattern:

Queue → Background Worker → SSE Stream → Browser

Production Tips

1. Disable response buffering

Some proxies buffer responses.

For Nginx:

proxy_buffering off;

2. Use keep-alive messages

If the connection stays silent too long, some proxies close it.

Send periodic heartbeat events.

3. Handle reconnects

Browsers automatically reconnect if the connection drops.

You can support Last-Event-ID for reliable resume.

When SSE Is Perfect

SSE is ideal for:

• AI streaming responses

• Live job progress

• Dev logs

• Real-time dashboards

• Notifications

And because it runs over plain HTTP, it works beautifully behind load balancers and CDNs.

Final Thoughts

Server-Sent Events are one of the most underrated features in modern web development.

With ASP.NET Core’s new Results.ServerSentEvents() API, building real-time experiences is now incredibly simple.

In many cases, you can replace complex WebSocket infrastructure with just:

IAsyncEnumerable + ServerSentEvents

Sometimes the best real-time solution is also the simplest one.

👉 Full working code available at:

🔗https://sourcecode.kanaiyakatarmal.com/ServerSentEvents

I hope you found this guide helpful and informative.

Thanks for reading!

If you enjoyed this article, feel free to share it and follow me for more practical, developer-friendly content like this.

With the introduction of the new XML-based .slnx solution format, Microsoft modernized solution files to align with the SDK-style project system and the broader .NET ecosystem.

If you’re maintaining enterprise .NET systems, building modular architectures, or simply trying to reduce Git merge conflicts, migrating to .slnx is a meaningful upgrade.

This article walks you through:

• Why .slnx exists

• What changes technically

• Step-by-step migration process

• CI/CD considerations

• Common pitfalls

• Enterprise rollout strategy

Why Move to .slnx?

The Old .sln Format

The legacy .sln format:

• Is not XML

• Is hard to diff

• Is difficult to merge

• Has limited tooling extensibility

• Contains GUID-heavy project references

• Was designed long before SDK-style projects

The New .slnx Format

The .slnx format:

• Is XML-based

• Uses structured elements

• Improves merge friendliness

• Aligns with modern MSBuild principles

• Reduces legacy solution cruft

• Plays better with automation

In short: .slnx makes solution files first-class citizens in the modern .NET ecosystem.

What Actually Changes?

Here’s a conceptual comparison.

Classic .sln

Project("{GUID}") = "MyApp", "MyApp.csproj", "{PROJECT-GUID}"
EndProject

XML .slnx

<Solution>
  <Project Path="MyApp/MyApp.csproj" />
</Solution>

The structure becomes:

• Declarative

• Clean

• Human-readable

• Scriptable

Step-by-Step Migration Guide

Step 1: Ensure Your Environment Supports .slnx

You need:

• Latest Visual Studio (Preview or stable supporting .slnx)

• Latest .NET SDK

• MSBuild updated

Check your SDK version:

dotnet --version

Upgrade if necessary.

Step 2: Convert the Solution

Microsoft provides a built-in conversion mechanism.

Option A – Using CLI

dotnet sln MySolution.sln migrate

Or:

dotnet new sln --format slnx

Option B – Using Visual Studio

1. Open existing .sln

2. Right-click Solution

3. Choose Save As

4. Select .slnx

Step 3: Validate the XML

Open the new .slnx.

You should see something like:

<Solution>
  <Project Path="src/App/App.csproj" />
  <Project Path="src/Library/Library.csproj" />
</Solution>

Validate:

• All projects are included

• Paths are correct

• No legacy GUID entries

Rollback Plan

If something fails:

1. Keep original .sln

2. Switch CI back

3. Revert branch

4. Document incompatibility

Migration should always be reversible in early stages.

Final Recommendations

✔ Test in a feature branch
✔ Upgrade SDK everywhere first
✔ Migrate small solutions first
✔ Communicate clearly to your team
✔ Remove .sln only after validation

Conclusion

The move from .sln to .slnx represents more than a format change.

It signals:

• Alignment with modern .NET architecture

• DevOps maturity

• Cleaner source control workflows

• Better automation potential

For greenfield projects, .slnx is the obvious choice.

For legacy systems, migration should be planned but it’s absolutely worth considering as part of modernization efforts.

I hope you found this guide helpful and informative.

Thanks for reading!

If you enjoyed this article, feel free to share it and follow me for more practical, developer-friendly content like this.

In this post, I’ll walk through a minimal ASP.NET Core Web API + SQLite example that does exactly that

Why this pattern matters

Most teams start with “just set timestamps in the API layer.” That works until:

• You forget to set a value in one endpoint

• You add background jobs that bypass controllers

• You duplicate the same logic across services and handlers

• You accidentally allow clients to overwrite system fields

A SaveChangesInterceptor solves this at the persistence boundary.
If an entity is tracked and saved, audit values are applied consistently.

What this demo app contains

Your EFCoreAuditInterceptor sample is intentionally focused:

• ASP.NET Core Web API

• EF Core + SQLite

• One entity: Customer

• One base type: AuditableEntity

• One interceptor: AuditInterceptor

• CRUD controller with no manual audit assignments

That keeps the concept sharp and easy to reuse.

Step 1: Define a shared auditable base class

All entities that need auditing inherit from a base type.

namespace EFCoreAuditInterceptor.Data
{
    public abstract class AuditableEntity
    {
        public DateTime CreatedOn { get; set; }
        public DateTime? UpdatedOn { get; set; }
    }
}

Why nullable UpdatedOn?
A new row may not have been updated yet, so null communicates that state clearly.

Step 2: Make your entity inherit it

namespace EFCoreAuditInterceptor.Data
{
    public class Customer : AuditableEntity
    {
        public int Id { get; set; }
        public string Name { get; set; } = string.Empty;
        public bool IsDeleted { get; set; }
    }
}

Now Customer automatically participates in auditing logic.

Step 3: Implement the SaveChangesInterceptor

This is the core of the pattern.

using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Diagnostics;

namespace EFCoreAuditInterceptor.Data
{
    public class AuditInterceptor : SaveChangesInterceptor
    {
        public override InterceptionResult<int> SavingChanges(
            DbContextEventData eventData,
            InterceptionResult<int> result)
        {
            ApplyAuditInfo(eventData.Context);
            return base.SavingChanges(eventData, result);
        }

        public override ValueTask<InterceptionResult<int>> SavingChangesAsync(
            DbContextEventData eventData,
            InterceptionResult<int> result,
            CancellationToken cancellationToken = default)
        {
            ApplyAuditInfo(eventData.Context);
            return base.SavingChangesAsync(eventData, result, cancellationToken);
        }

        private static void ApplyAuditInfo(DbContext? context)
        {
            if (context == null)
                return;

            foreach (var entry in context.ChangeTracker.Entries<AuditableEntity>())
            {
                if (entry.State == EntityState.Added)
                {
                    entry.Entity.CreatedOn = DateTime.UtcNow;
                }

                if (entry.State == EntityState.Modified)
                {
                    entry.Entity.UpdatedOn = DateTime.UtcNow;

                    // Prevent accidental overwrite of original CreatedOn value
                    entry.Property(x => x.CreatedOn).IsModified = false;
                }
            }
        }
    }
}

Important behavior:

• Added entities get CreatedOn

• Modified entities get UpdatedOn

• CreatedOn is protected during updates

Step 4: Register interceptor once in DI/DbContext pipeline

Your app already wires this via AddDbContext options (great).
Recommendation: keep that single registration path and avoid adding it again in OnConfiguring.

Program setup pattern:

builder.Services.AddScoped<AuditInterceptor>();

builder.Services.AddDbContext<AppDbContext>((sp, options) =>
{
    options.UseSqlite("Data Source=EFCoreAuditInterceptor.db");
    options.AddInterceptors(sp.GetRequiredService<AuditInterceptor>());
});

And DbContext stays lean:

public class AppDbContext : DbContext
{
    public AppDbContext(DbContextOptions<AppDbContext> options) : base(options) { }

    public DbSet<Customer> Customers => Set<Customer>();
}

Step 5: Keep controllers clean (no audit code)

Your controller already does this correctly: create/update customer values, call SaveChangesAsync, done.

Create action style:

var customer = new Customer
{
    Name = request.Name,
    IsDeleted = request.IsDeleted
};

_context.Customers.Add(customer);
await _context.SaveChangesAsync();

No CreatedOn/UpdatedOn assignment is needed anywhere in API logic.

End-to-end behavior

Create customer

Request:

POST /api/customers
{
  "name": "Alice",
  "isDeleted": false
}

Response includes auto-set CreatedOn:

{
  "id": 1,
  "name": "Alice",
  "isDeleted": false,
  "createdOn": "2026-03-02T10:15:21.123Z",
  "updatedOn": null
}

Update customer

Request:

PUT /api/customers/1
{
  "name": "Alice Cooper",
  "isDeleted": false
}

Response shows UpdatedOn stamped automatically while CreatedOn stays unchanged.

One demo note in your current project

You currently recreate the database on app startup (EnsureDeleted + EnsureCreated).
That is perfect for demos, but in real apps switch to EF Core migrations so data persists across runs.

Why this scales well

This approach stays maintainable because:

• Audit rules are centralized in one place

• Every save path is covered (controllers, services, jobs)

• API contracts remain focused on business data

• You reduce bugs from inconsistent timestamp handling

As your model grows, each new auditable entity simply inherits AuditableEntity.

Production hardening ideas (next steps)

If you evolve this demo into a production baseline, consider adding:

• CreatedBy and UpdatedBy (from authenticated user context)

• Soft-delete timestamps (DeletedOn, DeletedBy)

• Multi-tenant audit context

• UTC normalization tests around interceptor behavior

• Database defaults as a fallback safety net

Summary

• This project demonstrates a clean auditing pattern where EF Core automatically stamps CreatedOn and UpdatedOn at save time.

• The key idea is centralizing audit logic in a SaveChangesInterceptor, so application code stays simple and consistent.

• Entities inherit from a shared auditable base type, and the interceptor applies rules based on entity state (Added / Modified).

• This reduces duplication, prevents missed timestamp updates, and scales well as the domain grows.

• For production, keep single interceptor registration, use migrations (not recreate DB), and consider adding user-based audit fields.

Question for you: Which one do you find yourself using most often in your C# projects, and why?

👉 Full working code available at:

🔗https://sourcecode.kanaiyakatarmal.com/EFCoreAuditInterceptor

I hope you found this guide helpful and informative.

Thanks for reading!

If you enjoyed this article, feel free to share it and follow me for more practical, developer-friendly content like this.

But here’s the uncomfortable truth: most APIs are technically functional… and architecturally flawed.

After reviewing common patterns highlighted in Top 10 Mistakes in REST API Design, I realized something important:

👉 Most API problems aren’t about code.
👉 They’re about design decisions.

Let’s break down the 10 most common REST API mistakes and what to do instead.

1. Using Verbs in Endpoint URLs

❌ Mistake:

/createUser
/deleteOrder/:id

This mixes actions into URLs.

✅ Best Practice:
Use nouns. Let HTTP methods define the action.

POST   /users        → create user
DELETE /orders/{id}  → delete order

Your endpoints should represent resources, not actions.

2. Ignoring Proper Use of HTTP Methods

Each HTTP method has a semantic meaning:

• GET → Read

• POST → Create

• PUT/PATCH → Update

• DELETE → Remove

❌ Mistake:
Using GET to delete something or POST for idempotent updates.

This breaks expectations and can cause serious caching or security issues.

3. Overloading 200 OK

Returning 200 OK for everything — even errors — is one of the most common API design sins.

❌ Example:

200 OK
{
  "error": "User not found"
}

✅ Use proper status codes:

• 201 → Created

• 400 → Bad Request

• 404 → Not Found

• 409 → Conflict

• 500 → Server Error

Status codes are not optional metadata — they are part of the API contract.

4. Inconsistent or Vague Error Handling

Two dangerous patterns:

• Generic error messages

• Exposing stack traces to clients

✅ Better approach:

Standardize error responses:

{
  "code": "USER_NOT_FOUND",
  "message": "User with ID 123 does not exist."
}

Clear. Actionable. Secure.

5. Not Versioning Your API

Launching without versioning feels fast.

It’s also short-sighted.

❌ Mistake:

/users

✅ Better:

/v1/users

Or use header-based versioning.

Versioning allows:

• Backward compatibility

• Gradual deprecation

• Safer evolution

Without it, every breaking change becomes a production risk.

6. Poor Resource Structure & Over-Nesting

Deeply nested URLs become painful quickly.

❌ Example:

/users/{id}/orders/{orderId}/items/{itemId}/reviews/{reviewId}

Hard to maintain. Hard to scale.

✅ Instead:
Use logical nesting but avoid excessive depth.
Consider top-level resources with relational links.

Example:

/reviews/{id}

Keep URLs clean and predictable.

7. No Pagination, Filtering, or Sorting

Returning entire datasets is a performance disaster waiting to happen.

❌ Mistake:

GET /users

Returns 50,000 records.

✅ Implement pagination:

GET /users?limit=20&offset=40

Also allow:

• Filtering (?status=active)

• Sorting (?sort=created_at)

This dramatically improves performance and client flexibility.

8. Ignoring Security & Throttling

APIs without HTTPS, authentication, or rate limiting are exposed systems.

Minimum standards today:

• Always use HTTPS

• Implement authentication (OAuth2, JWT)

• Add rate limiting

Even a simple limit like 100 requests per minute per user can prevent abuse.

Security is not an enhancement. It’s foundational.

9. Inconsistent Naming Conventions

Mixing naming styles makes APIs confusing:

• /user

• /users

• /userList

• camelCase vs snake_case

✅ Best Practice:

• Use plural nouns: /users

• Choose one casing style and stick to it

Consistency reduces cognitive load for developers.

10. Ignoring Caching & Performance Tools

APIs that don’t use caching headers are wasting performance potential.

Use:

• ETag

• Cache-Control

For long-running tasks:

202 Accepted

Then provide a status endpoint.

Example:

POST /reports
→ 202 Accepted

GET /reports/{id}/status

Asynchronous processing makes your API scalable.

The Real Pattern Behind These Mistakes

Notice something?

Every mistake above falls into one of three categories:

1. Breaking HTTP semantics

2. Ignoring scalability

3. Failing to think long-term

Good API design isn’t about being clever.

It’s about being predictable.

Because predictable APIs:

• Scale better

• Break less

• Are loved by developers

REST API Design Checklist (Save This)

Before shipping your next API:

✔ Resource-based URLs
✔ Correct HTTP methods
✔ Meaningful status codes
✔ Standardized error responses
✔ Versioning strategy
✔ Logical, shallow structure
✔ Pagination + filtering + sorting
✔ HTTPS + authentication + rate limiting
✔ Consistent naming conventions
✔ Caching + async support

If you get these 10 right, you’re ahead of most APIs in production.

Ship thoughtfully.

Your future self (and every developer who integrates with you) will thank you.

I hope you found this guide helpful and informative.

Thanks for reading!

If you enjoyed this article, feel free to share it and follow me for more practical, developer-friendly content like this.

If you’ve ever wondered:

• When should I use AddTransient vs AddScoped?

• Why does using a Singleton sometimes cause bugs?

• What actually happens per request?

This article will clear that up using simple explanations and visual diagrams.

What Is a Service Lifetime?

In ASP.NET Core, a service lifetime defines how long an object lives in memory and how often a new instance is created.

.NET Core provides three built-in lifetimes:

1. Transient

2. Scoped

3. Singleton

Let’s break them down one by one.

1. Transient Lifetime

Definition:
A new instance is created every time the service is requested.

Registration

services.AddTransient<IService, Service>();

How It Works (from the diagram)

• Every request gets a brand-new object

• Even within the same request, multiple injections create multiple instances

When to Use Transient

✔ Lightweight services
✔ Stateless services
✔ Helper or utility classes

Example

public class EmailFormatter
{
    public string Format(string message) => $"Email: {message}";
}

⚠️ Avoid When

• The service holds state

• The service is expensive to create

Think of Transient as:

“Create it, use it, throw it away.”

2. Scoped Lifetime

Definition:
One instance is created per request (scope).

Registration

services.AddScoped<IService, Service>();

How It Works (from the diagram)

• Each HTTP request gets one instance

• The same instance is reused within that request

• A new request = a new instance

When to Use Scoped

✔ Database contexts (DbContext)
✔ Business logic tied to a request
✔ Services that track request-specific data

Example

public class OrderService
{
    private readonly Guid _requestId = Guid.NewGuid();
}

Every HTTP request gets its own OrderService, but controllers inside the same request share it.

⚠️ Important Rule

Never inject a Scoped service into a Singleton

This will cause runtime errors or subtle bugs.

Think of Scoped as:

“One service per web request.”

3. Singleton Lifetime

Definition:
A single instance is created and shared for the entire application lifetime.

Registration

services.AddSingleton<IService, Service>();

How It Works (from the diagram)

• Created once when the app starts

• Shared across all requests and users

• Lives until the application shuts down

When to Use Singleton

✔ Configuration services
✔ Caching services
✔ Logging services
✔ Thread-safe, read-only services

Example

public class AppSettingsCache
{
    public Dictionary<string, string> Settings { get; } = new();
}

⚠️ Be Careful

• Must be thread-safe

• Shared state can cause race conditions

• Never inject Scoped or Transient services that depend on request data

Think of Singleton as:

“One object to rule them all.”

Common Mistakes (and How to Avoid Them)

❌ Using Singleton for database access
✅ Use Scoped instead

❌ Storing user-specific data in Singleton
✅ Keep user data request-scoped

❌ Overusing Transient for heavy services
✅ Use Scoped or Singleton where appropriate

Final Thoughts

Choosing the right service lifetime is not just about performance—it’s about correctness, scalability, and safety.

If you remember just one thing:

• Transient → lightweight & stateless

• Scoped → request-based logic

• Singleton → shared & thread-safe

Pick wisely, and your ASP.NET Core apps will thank you.

I hope you found this guide helpful and informative.

Thanks for reading!

If you enjoyed this article, feel free to share it and follow me for more practical, developer-friendly content like this.

Instead of remembering to add these conditions everywhere, EF Core gives us a powerful tool to automate this logic: Global Query Filters.

In this article, we’ll explore what they are, why they matter, and how to use them effectively—including a practical soft-delete example you can copy into your own project.

What Are Global Query Filters?

A global query filter is a LINQ expression automatically applied to an entity every time EF Core generates a query.

Once defined:

• You don’t have to add the filter manually to each query

• EF Core injects the filter into all queries, including navigation loads and LINQ queries

• You can still bypass the filter when needed

This leads to cleaner, safer, and more maintainable code especially when dealing with soft deletes, permissions, or multi-tenant data.

The Soft Delete Scenario

Soft deletion is extremely common. Instead of physically deleting a record from the database, you mark it as deleted:

public class Customer
{
    public int Id { get; set; }
    public bool IsDeleted { get; set; }
}

Without global filters, every query would need:

.Where(c => !c.IsDeleted)

And it’s only a matter of time before someone forgets it.

Applying a Global Query Filter

Global filters are configured inside OnModelCreating.

Here’s your example in full:

public class CustomerContext : DbContext
{
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        // Global query filter for soft delete
        modelBuilder.Entity<Customer>()
            .HasQueryFilter(p => !p.IsDeleted);
    }
}

From this moment on, EF Core automatically adds:

WHERE IsDeleted = 0

to every query involving Customer.

✅ Using Queries with the Filter Applied

// Filtered query: soft-deleted customers are excluded
var activeCustomers = await context.Customers
    .ToListAsync(cancellationToken);

Even though you didn’t specify a condition, EF Core did it for you behind the scenes.
This ensures your application never accidentally exposes deleted or archived records.

Bypassing the Filter When Needed

Sometimes you need access to all customers—for example, an admin tool, an audit job, or a restore action.

EF Core makes that easy:

// Unfiltered query: includes soft-deleted customers
var customers = await context.Customers
    .IgnoreQueryFilters()
    .ToListAsync(cancellationToken);

This gives you full control while still keeping your main queries safe.

More Advanced: Named Global Query Filters (EF Core 10)

EF Core 10 introduces named global filters, letting you toggle specific filters on and off (similar to feature flags for filtering).

This is especially useful when you have multiple filters on the same entity, such as:

• IsDeleted == false

• IsArchived == false

• TenantId == CurrentTenant

You can selectively disable only one filter instead of removing all of them via IgnoreQueryFilters().

This feature comes from a great community discussion and design proposal—if you’re curious, Tim Deschryver provides a deep dive here: (link you provided).

Why Global Query Filters Are So Powerful

The benefits that scale with your application

• Centralized filtering logic

• Prevents accidental data exposure

• Great for soft delete, multi-tenancy, and security rules

• Applies to LINQ queries and navigation properties

Once you start using them, it’s hard to imagine building an EF Core application without them.

Common Pitfalls to Avoid

• Filters are applied to navigation properties, which may cause unexpected query results if you’re not aware.

• Owned entity types can’t have filters.

• Filters are cached per model, so dynamic per-request values require storing state in the DbContext (e.g., current tenant).

Looking Ahead: Named Filters in EF Core 10

Fine-grained control for advanced scenarios

EF Core 10 introduces named global query filters, allowing developers to disable specific filters instead of all filters at once.

This is especially useful when combining:

• Soft delete

• Archiving

• Multi-tenancy

If you’re curious about the detailed proposal and examples, check out the original discussion referenced in your link.

Final Thoughts

Global Query Filters are one of EF Core’s most elegant ways to simplify your code and enforce data rules consistently. For scenarios like soft delete, they provide:

• Cleaner code

• Safer access patterns

• More maintainable systems

Start with a simple soft-delete filter like the one above, and soon you’ll find ways to use them across your entire application.

👉 Full working code available at:

🔗https://sourcecode.kanaiyakatarmal.com/EFCoreGlobalQueryFilters

I hope you found this guide helpful and informative.

Thanks for reading!

If you enjoyed this article, feel free to share it and follow me for more practical, developer-friendly content like this.

With EF Core 10, that finally changes.

Why Outer Joins Matter

In real projects, we often need to fetch all entities from one table, including those with no related data. For example:

• A campaign may exist even if no assets were uploaded yet

• A file could be imported before a campaign is attached to it

• Reports often need complete datasets, even with missing associations

Until now, LINQ made this harder than necessary.

EF Core 10 changes that elegantly.

Example Scenario

Let’s imagine a common marketing structure:

• Campaign → a promotional or marketing effort

• CampaignAsset → images, files, or collateral linked to the campaign

Entity Definitions

public class Campaign
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
}

public class CampaignAsset
{
    public int Id { get; set; }
    public int CampaignId { get; set; }
    public string FileName { get; set; } = string.Empty;
}

Our goal: retrieve all campaigns — even those without assets.

EF Core 10: Left Join (Left Outer Join)

EF Core 10 introduces a clean new operator: .LeftJoin(), making this operation finally feel natural.

var query = context.Campaigns
    .LeftJoin(
        context.CampaignAssets,
        campaign => campaign.Id,
        asset => asset.CampaignId,
        (campaign, asset) => new
        {
            Campaign = campaign,
            Asset = asset
        });

This is LINQ the way it was meant to be.

SQL Generated

SELECT *
FROM Campaigns AS c
LEFT JOIN CampaignAssets AS a
    ON c.Id = a.CampaignId;

EF Core 10: Right Join (Right Outer Join)

Less common, but extremely useful when reconciling external data sources or validating imported files.

var query = context.Campaigns
    .RightJoin(
        context.CampaignAssets,
        campaign => campaign.Id,
        asset => asset.CampaignId,
        (campaign, asset) => new
        {
            Campaign = campaign,
            Asset = asset
        });

Right joins now require no workaround — finally.

Before vs After EF Core 10

❌ Old Approach — Functional, but clunky

var query =
    from c in context.Campaigns
    join a in context.CampaignAssets
        on c.Id equals a.CampaignId into assets
    from a in assets.DefaultIfEmpty()
    select new { c, a };

It works — but the intent is buried in syntax.

✅ New EF Core 10 Approach — Elegant & expressive

var query = context.Campaigns
    .LeftJoin(
        context.CampaignAssets,
        c => c.Id,
        a => a.CampaignId,
        (c, a) => new { c, a });

Readable. Direct. Maintainable.
This is what modern LINQ should look like.

Final Thoughts

EF Core 10 didn’t just add an operator — it improved the developer experience.
Outer joins are finally straightforward in LINQ, making queries easier to read, write, and teach.

If you’re using EF Core professionally, this is an upgrade worth adopting.
Clean code scales — and this feature is a perfect example.

👉 Full working code available at:

🔗https://sourcecode.kanaiyakatarmal.com/EFCore10OuterJoins

I hope you found this guide helpful and informative.

Thanks for reading!

If you enjoyed this article, feel free to share it and follow me for more practical, developer-friendly content like this.

The image above highlights seven widely-used approaches:

1. REST API

REST (Representational State Transfer) is the most commonly used architectural style for building web services.

Key characteristics:

• Works over HTTP

• Stateless

• Supports JSON, XML, and other data formats

• Easy to use and widely adopted

Best for:

• CRUD operations

• Standard web/mobile APIs

• Public APIs (e.g., Twitter, GitHub)

2. GraphQL

GraphQL is a query language for APIs created by Facebook.

Why it’s popular:

• Client can request exactly the data needed

• Reduces over-fetching and under-fetching

• Single endpoint for all queries and mutations

Best for:

• Complex data relationships

• Mobile apps (bandwidth-sensitive)

• Frontend-heavy applications

3. SOAP API

SOAP (Simple Object Access Protocol) is a strict protocol used mostly in enterprise systems.

Characteristics:

• Enforces strict standards

• Built-in security and error handling

• Uses XML

Best for:

• Banking

• Telecom

• Payment gateways

• Government systems

4. gRPC

Google’s Remote Procedure Call framework, powered by HTTP/2.

Benefits:

• High performance

• Bi-directional streaming

• Strongly typed contracts using Protocol Buffers

• Lightweight and fast

Best for:

• Microservices communication

• Real-time communication

• Low-latency systems

5. Webhooks

Webhooks are event-driven HTTP callbacks.

How they work:

• Server notifies another system when an event occurs

• No constant polling required

Use cases:

• Payment status update

• Slack notifications

• CI/CD triggers

Best for:

• Instant push notifications between systems

6. WebSockets

WebSockets enable persistent, full-duplex communication between client and server.

Advantages:

• Real-time updates

• Single TCP connection

• Low latency

Best for:

• Live dashboards

• Chat applications

• Multiplayer games

7. WebRTC

WebRTC (Web Real-Time Communication) enables browser-to-browser media communication without plugins.

Capabilities:

• Audio/video streaming

• Peer-to-peer connections

• Data channels

Use cases:

• Video conferencing (Zoom, Meet)

• Live streaming

• Virtual events

How to Choose the Right Technology

When you need standard CRUD operations

Use REST API

• Easy to implement

• Well supported everywhere

• Perfect for typical web/mobile apps

When you want efficient data fetching

Use GraphQL

• Clients can request only required fields

• Prevents over-fetching/under-fetching

• Best for complex UI data requirements

When your system requires high security & strict contracts

Use SOAP

• Built-in security features

• Strong validation

• Ideal for enterprise & banking

When you need high-performance internal communication

Use gRPC

• Faster than REST

• Low-latency communication

• Ideal for microservices

When you want event-based callbacks

Use Webhooks

• Push-based notifications

• No need for polling

• Great for payment/platform integrations

When you need real-time, continuous messaging

Use WebSockets

• Persistent connection

• Bi-directional communication

• Ideal for chats, dashboards, games

When you want direct peer-to-peer audio/video/data transfer

Use WebRTC

• Browser-to-browser communication

• Low latency

• Ideal for video calling & streaming

Quick Decision Flow (Simple)

• CRUD APIs? → REST

• Complex queries? → GraphQL

• Enterprise compliance/security? → SOAP

• Service-to-service speed? → gRPC

• Trigger events externally? → Webhooks

• Real-time messages? → WebSockets

• Video/audio communication? → WebRTC

Conclusion

Each of these communication technologies solves a different problem. Understanding their strengths helps engineers architect reliable, scalable, and efficient systems.

Instead of comparing them as competitors, think of them as tools in a toolbox—choose the one that fits the job.

I hope you found this guide helpful and informative.

Thanks for reading!

If you enjoyed this article, feel free to share it and follow me for more practical, developer-friendly content like this.

What is the Strategy Pattern?

The Strategy Pattern is a behavioral design pattern that allows you to define a family of algorithms, encapsulate each one, and make them interchangeable. Instead of hardcoding multiple conditional statements or behaviors, you can dynamically change the behavior of a class at runtime.

In simpler terms:

“Encapsulate algorithms in separate classes and let the client choose which one to use.”

When to Use the Strategy Pattern

The Strategy Pattern is particularly useful when:

• You have multiple ways to perform a specific task.

• You want to avoid complex if-else or switch statements.

• You want to make your code open for extension but closed for modification (following the Open/Closed Principle).

Examples in real-world scenarios:

• Payment processing (Credit Card, PayPal, Cryptocurrency)

• Sorting algorithms (QuickSort, MergeSort, BubbleSort)

• Logging strategies (File, Database, Console)

Anatomy of the Strategy Pattern

The Strategy Pattern consists of three main components:

1. Strategy Interface: Declares a common interface for all supported algorithms.

2. Concrete Strategies: Implement the Strategy interface with specific algorithms.

3. Context: Maintains a reference to a Strategy object and delegates behavior execution to it.

mplementing Strategy Pattern in C#

Let’s walk through a real-world example: a Payment Processor.

Step 1: Define the Strategy Interface

public interface IPaymentStrategy
{
    void Pay(decimal amount);
}

Step 2: Create Concrete Strategies

public class CreditCardPayment : IPaymentStrategy
{
    private string _cardNumber;

    public CreditCardPayment(string cardNumber)
    {
        _cardNumber = cardNumber;
    }

    public void Pay(decimal amount)
    {
        Console.WriteLine($”Paid {amount:C} using Credit Card {_cardNumber}”);
    }
}

public class PayPalPayment : IPaymentStrategy
{
    private string _email;

    public PayPalPayment(string email)
    {
        _email = email;
    }

    public void Pay(decimal amount)
    {
        Console.WriteLine($”Paid {amount:C} using PayPal account {_email}”);
    }
}

Step 3: Implement the Context

public class PaymentProcessor
{
    private IPaymentStrategy _paymentStrategy;

    public PaymentProcessor(IPaymentStrategy paymentStrategy)
    {
        _paymentStrategy = paymentStrategy;
    }

    public void SetPaymentStrategy(IPaymentStrategy paymentStrategy)
    {
        _paymentStrategy = paymentStrategy;
    }

    public void ProcessPayment(decimal amount)
    {
        _paymentStrategy.Pay(amount);
    }
}

Step 4: Use the Strategy Pattern

class Program
{
    static void Main(string[] args)
    {
        var creditCardPayment = new CreditCardPayment("1234-5678-9876-5432");
        var paypalPayment = new PayPalPayment("user@example.com");

        var processor = new PaymentProcessor(creditCardPayment);
        processor.ProcessPayment(100); // Paid 100 using Credit Card 1234-5678-9876-5432

        processor.SetPaymentStrategy(paypalPayment);
        processor.ProcessPayment(200); // Paid 200 using PayPal account user@example.com
    }
}

Advantages of the Strategy Pattern

• Flexibility: Easily swap algorithms without modifying the client.

• Single Responsibility: Each algorithm is encapsulated in its own class.

• Open/Closed Principle: Adding a new algorithm does not require changing existing code.

Disadvantages

• Increased number of classes: Each algorithm requires a separate class.

• Complexity: Can add complexity if overused for simple tasks.

Real-World Example

Imagine an e-commerce platform where you need to implement different shipping methods: Standard Shipping, Express Shipping, and Overnight Shipping. Using the Strategy Pattern, you can create a flexible system where new shipping strategies can be added without modifying the core checkout logic.

Conclusion

The Strategy Pattern is a powerful design pattern for situations where multiple algorithms exist, and you want to dynamically select the best one at runtime. By encapsulating algorithms into separate classes and using a common interface, your code becomes cleaner, more maintainable, and easily extendable.

Using the Strategy Pattern in C# can drastically reduce your conditional logic, improve code readability, and enhance scalability in large applications.

A class in C# is a reference type, meaning it is stored on the heap, and assignments create references to the same object. Classes support inheritance, encapsulation, and polymorphism.

🔹 Ready to refactor your code with Strategy Pattern?

Which part of your current project could benefit from dynamically swapping behaviors?

👉 Full working code available at:

🔗https://sourcecode.kanaiyakatarmal.com/StrategyPattern

I hope you found this guide helpful and informative.

Thanks for reading!

If you enjoyed this article, feel free to share it and follow me for more practical, developer-friendly content like this.

What is gRPC?

gRPC (Google Remote Procedure Call) is a modern, open-source framework built on HTTP/2 and uses Protocol Buffers (protobuf) for serialization. Instead of sending verbose JSON payloads, protobuf creates compact, binary-encoded messages that are faster and smaller.

In simple words:

👉 REST = “Send me data”
👉 gRPC = “Call my function remotely, as if it existed locally”

🧠 Why gRPC in .NET Core?

Microsoft has deeply integrated gRPC support in .NET Core, offering developers:

✅ Strong type safety
✅ Contract-driven development
✅ First-class tooling support
✅ Auto-generated clients

This reduces boilerplate and ensures consistent communication between services.

⚡ gRPC vs REST (High-Level Differences)

gRPC shines when you need:

• Microservice-to-microservice calls

• Real-time streaming

• High request frequency

• Maximum performance

REST is still great for:

• Public/external APIs

• Simple CRUD operations

• Browsers without gRPC support

They are not competitors — they serve different purposes.

Project Structure Overview

Our microservice uses some common building blocks:

• Product Model — represents the domain entity

• AppDbContext — EF Core database context

• Proto Contract — gRPC messages & RPC definitions

• ProductService — implementation of RPC endpoints

/GRPCSample
 ├── Data
 ├── Models
 ├── Services
 ├── Protos
 └── Program.cs

The Entity (Product)

Inside Models/Product.cs, we define the Product entity used by EF Core:

public class Product
{
    public Guid Id { get; set; }
    public required string Name { get; set; }
    public required string Description { get; set; }
    public decimal Price { get; set; }
    public DateTime Created { get; set; }
    public DateTime Updated { get; set; }
    public string? Tags { get; set; }
}

Couple of noteworthy things here:

• required ensures properties must be set.

• Created and Updated manage timestamps.

• Tags is optional.

Database Context Setup

Using Entity Framework Core, we define a context exposing the products table:

public class AppDbContext : DbContext
{
    public AppDbContext(DbContextOptions<AppDbContext> options)
        : base(options) {}

    public DbSet<Product> Products => Set<Product>();
}

This allows EF Core to map the Product entity automatically.

Defining gRPC Contracts With Protobuf

Inside product.proto, we define messages and service operations:

syntax = "proto3";

option csharp_namespace = "GRPCSample";

package product;

service ProductsServiceProto {
  rpc CreateProduct(CreateProductRequest) returns (CreateProductResponse);
  rpc GetProduct(GetProductRequest) returns (GetProductResponse);
  rpc ListProduct(ListProductsRequest) returns (ListProductsResponse);
  rpc UpdateProduct(UpdateProductRequest) returns (UpdateProductResponse);
  rpc DeleteProduct(DeleteProductRequest) returns (DeleteProductResponse);
}

message ProductModel {
  string id = 1;
  string name = 2;
  string description = 3;
  double price = 4;
  string created_at = 5;
  string updated_at = 6;
  string tag = 7;
}

All communication between client and server is strongly typed and version-safe.

Registering the Proto in the Project File

<ItemGroup>
   <Protobuf Include="Protos\product.proto" GrpcServices="Server" />
</ItemGroup>

And reference the gRPC package:

<PackageReference Include="Grpc.AspNetCore" Version="2.71.0" />

Implementing the Service Layer

public class ProductService : ProductsServiceProto.ProductsServiceProtoBase

Create Product

public override async Task<CreateProductResponse> CreateProduct(CreateProductRequest request, ServerCallContext context)
{
    var productItem = new Product { ... };

    _dbContext.Products.Add(productItem);
    await _dbContext.SaveChangesAsync();
}

Get Product by ID

var product = await _dbContext.Products.FindAsync(productId);

Update Product

existingProduct.Updated = DateTime.UtcNow;
await _dbContext.SaveChangesAsync();

Delete Product

dbContext.Products.Remove(product);
await _dbContext.SaveChangesAsync();

Mapping Entity → Proto Model

private static ProductModel MapToProductModel(Product product)
{
    return new ProductModel
    {
        Id = product.Id.ToString(),
        Name = product.Name,
        ...
    };
}

Creating and Running Migrations

Start by creating the initial migration:

dotnet ef migrations add InitialCreate

Apply the migration to create the database:

dotnet ef database update

Test gRPC Services with Postman

Create a New gRPC Request

Configure the gRPC Request Interface

Verify Successful Import

Test Create Product Request

Output:

🧁 What You Learned

By now, we’ve covered:

• Creating Proto contracts

• Generating gRPC server-side code

• Implementing CRUD operations

• Using EF Core for persistence

This template can easily evolve into:

• Event-driven microservices

• Inventory platforms

• Catalog services

• SaaS product management

🔥 Final Thoughts

gRPC isn’t here to replace REST.
Instead, it solves internal service communication where:

• Low latency matters

• High throughput is required

• Contract safety reduces regressions

Combine this with streaming,
and gRPC becomes a serious toolkit for modern architectures.

💬 Are you using gRPC in production?

What’s the biggest benefit you’ve seen?

Comment below 👇

👉 Full working code available at:

🔗http://sourcecode.kanaiyakatarmal.com/GRPC

I hope you found this guide helpful and informative.

Thanks for reading!

If you enjoyed this article, feel free to share it and follow me for more practical, developer-friendly content like this.

In this guide, we’ll explore:

• 🔸 What AES-256 is and why it matters

• 🔸 How to implement AES-256 encryption and decryption in C#

• 🔸 Practical tips for using it securely in real-world apps

🧩 What is AES-256?

AES (Advanced Encryption Standard) is a symmetric encryption algorithm — meaning the same key is used to both encrypt and decrypt data.

The “256” in AES-256 refers to the key size — a 256-bit key provides 2²⁵⁶ possible combinations, making brute-force attacks virtually impossible.

It’s widely used in:

• Secure messaging apps

• Encrypted databases

• File and password storage

• Network communications (TLS, VPNs, etc.)

🧩 What is AES-256?

AES (Advanced Encryption Standard) is a symmetric encryption algorithm — meaning the same key is used to both encrypt and decrypt data.

The “256” in AES-256 refers to the key size — a 256-bit key provides 2²⁵⁶ possible combinations, making brute-force attacks virtually impossible.

It’s widely used in:

• Secure messaging apps

• Encrypted databases

• File and password storage

• Network communications (TLS, VPNs, etc.)

⚙️ Implementing AES-256 Encryption in C#

C# makes encryption straightforward through the System.Security.Cryptography namespace.
Let’s implement a helper class that can encrypt and decrypt strings using AES-256.

🔧 Full Code Example

using System;
using System.IO;
using System.Security.Cryptography;
using System.Text;

public static class AesEncryptionHelper
{
    // Encrypt a plain text string using AES-256
    public static string Encrypt(string plainText, string key)
    {
        using Aes aes = Aes.Create();
        aes.Key = SHA256.HashData(Encoding.UTF8.GetBytes(key)); // Generate a 256-bit key
        aes.GenerateIV(); // Create a random IV for each encryption

        using var encryptor = aes.CreateEncryptor(aes.Key, aes.IV);
        using var ms = new MemoryStream();
        ms.Write(aes.IV, 0, aes.IV.Length); // Prepend IV to ciphertext

        using (var cs = new CryptoStream(ms, encryptor, CryptoStreamMode.Write))
        using (var writer = new StreamWriter(cs))
        {
            writer.Write(plainText);
        }

        return Convert.ToBase64String(ms.ToArray());
    }

    // Decrypt a cipher text string using AES-256
    public static string Decrypt(string cipherText, string key)
    {
        byte[] fullCipher = Convert.FromBase64String(cipherText);
        using Aes aes = Aes.Create();
        aes.Key = SHA256.HashData(Encoding.UTF8.GetBytes(key));

        // Extract IV from the beginning
        byte[] iv = new byte[aes.BlockSize / 8];
        Array.Copy(fullCipher, iv, iv.Length);

        int cipherStartIndex = iv.Length;
        int cipherLength = fullCipher.Length - cipherStartIndex;

        using var decryptor = aes.CreateDecryptor(aes.Key, iv);
        using var ms = new MemoryStream(fullCipher, cipherStartIndex, cipherLength);
        using var cs = new CryptoStream(ms, decryptor, CryptoStreamMode.Read);
        using var reader = new StreamReader(cs);
        return reader.ReadToEnd();
    }
}

🧠 Example Usage

string secretKey = "MySuperSecretKey@123";
string plainText = "Hello AES 256 Encryption!";

string encrypted = AesEncryptionHelper.Encrypt(plainText, secretKey);
Console.WriteLine($"🔒 Encrypted: {encrypted}");

string decrypted = AesEncryptionHelper.Decrypt(encrypted, secretKey);
Console.WriteLine($"🔓 Decrypted: {decrypted}");

🧩 How It Works

1. Key Derivation:
   We use SHA256.HashData() to convert the input key into a 256-bit key required by AES-256.

2. IV (Initialization Vector):
   A random IV is generated each time to ensure the same plain text never produces the same cipher text.

3. CryptoStream:
   Handles the heavy lifting of encrypting and decrypting data streams securely.

4. Base64 Encoding:
   Converts binary data to text — making it easy to store or transmit over APIs, JSON, or databases.

🧱 Best Practices for AES-256 in .NET

✅ Use a strong, random key — don’t hard-code it in your source code.
✅ Always use a unique IV for every encryption (as shown above).
✅ Store key and IV securely (e.g., Azure Key Vault, AWS KMS, or environment variables).
✅ Prefer AES-GCM mode for modern applications if authenticated encryption (integrity + confidentiality) is needed.
✅ Avoid reusing encryption logic for passwords — use hashing algorithms like PBKDF2, bcrypt, or Argon2 instead.

🧾 When to Use AES-256

Use AES-256 when:

• You need to store confidential configuration data (connection strings, API keys).

• You must encrypt local files or backups.

• You’re transmitting sensitive data between services without TLS.

🏁 Wrapping Up

AES-256 provides a powerful, efficient, and secure way to encrypt data in C#.
With just a few lines of code, you can protect your application from data leaks and unauthorized access.

💬 How are you currently handling encryption in your .NET applications?
Have you tried implementing AES-256 or another cipher?

👉 Full working code available at:

🔗https://sourcecode.kanaiyakatarmal.com/AesEncryptionSample

I hope you found this guide helpful and informative.

Thanks for reading!

If you enjoyed this article, feel free to share it and follow me for more practical, developer-friendly content like this.

1. Class

A class in C# is a reference type, meaning it is stored on the heap, and assignments create references to the same object. Classes support inheritance, encapsulation, and polymorphism.

Example

public class Person
{
    public string Name { get; set; }
    public int Age { get; set; }

    public Person(string name, int age)
    {
        Name = name;
        Age = age;
    }
}

// Usage
var person1 = new Person("Alice", 25);
var person2 = person1;
person2.Age = 30;

Console.WriteLine(person1.Age); // Output: 30

Key Points:

• Reference type → multiple variables can reference the same object.

• Mutable by default.

• Supports inheritance and polymorphism.

• Good for large, complex objects with behavior.

2. Record

A record is a reference type designed for immutable data models. Records are great for data-centric objects, like DTOs or configuration settings, and support value-based equality out of the box.

Example

public record PersonRecord(string Name, int Age);

// Usage
var record1 = new PersonRecord("Bob", 30);
var record2 = record1 with { Age = 35 };

Console.WriteLine(record1.Age); // Output: 30
Console.WriteLine(record2.Age); // Output: 35

Key Points:

• Immutable by default (though you can define mutable properties).

• Supports value equality (Equals and GetHashCode based on properties).

• Ideal for immutable DTOs, event data, or simple models.

• Supports with expressions for easy copying with changes.

3. Struct

A struct in C# is a value type, stored on the stack (or inline in arrays). Assignments copy the value, making structs lightweight and suitable for performance-critical scenarios.

public struct PersonStruct
{
    public string Name { get; set; }
    public int Age { get; set; }

    public PersonStruct(string name, int age)
    {
        Name = name;
        Age = age;
    }
}

// Usage
var struct1 = new PersonStruct("Charlie", 28);
var struct2 = struct1;
struct2.Age = 35;

Console.WriteLine(struct1.Age); // Output: 28

Key Points:

• Value type → copying creates a new independent object.

• Lightweight, good for small data structures.

• Cannot have inheritance.

• Best for performance-sensitive, small, immutable objects.

When to Use What?

Choosing between class, record, and struct depends on the nature of your data and how you intend to use it. Use a class when you have complex objects that are mutable, require identity, or need behavior such as methods, inheritance, or polymorphism. Classes are great for large, behavior-rich entities but come with heap allocation and garbage collection overhead.

Use a record when your focus is on immutable data and value-based equality. Records are ideal for data transfer objects (DTOs), configuration settings, or event data where the content matters more than the object identity. They offer concise syntax and built-in equality comparison, making it easy to work with immutable models.

Use a struct for small, lightweight objects where performance is critical. Structs are value types and are stored on the stack, so copying creates independent copies without heap allocation. They are perfect for small data structures such as points, coordinates, or other numeric containers. However, avoid large structs or structs that require inheritance, as this can lead to performance issues or unnecessary complexity.

Rule of thumb: choose a class for objects with behavior, a record for immutable data, and a struct for small, high-performance value objects.

Conclusion

Understanding the difference between class, record, and struct helps you write cleaner, efficient, and maintainable C# code. Choosing the right type depends on mutability, size, and identity requirements of your objects.

• Class → mutable, identity-focused, behavior-rich.

• Record → immutable, data-centric, value-based equality.

• Struct → lightweight, value-focused, high-performance.

Choosing wisely can improve performance, readability, and reduce subtle bugs related to object copying or equality.

🔹 Example Summary

Person person = new("Alice", 25);          // Class
PersonRecord record = new("Bob", 30);      // Record
PersonStruct pStruct = new("Charlie", 28); // Struct

💡 Question for you: Which one do you find yourself using most often in your C# projects, and why?

👉 Full working code available at:

🔗https://sourcecode.kanaiyakatarmal.com/ClassvsRecordvsStruct

I hope you found this guide helpful and informative.

Thanks for reading!

If you enjoyed this article, feel free to share it and follow me for more practical, developer-friendly content like this.

🚧 The Problem with Traditional Exception Handling

Before .NET 8, developers typically relied on middleware or filters to handle exceptions globally.
While those approaches worked, they often led to:

• ⚙️ Complex middleware configurations

• 📦 Scattered exception handling logic

• 🧪 Difficulty in testing

• ⚠️ Inconsistent or unclear error responses

As projects scaled, maintaining a consistent global error strategy became a real challenge.

💡 Introducing IExceptionHandler

The IExceptionHandler interface, part of the Microsoft.AspNetCore.Diagnostics namespace, offers a modern and standardized solution.

🔑 Key Benefits:

✅ Centralized handling – All exceptions flow through a single pipeline
🧩 Flexibility – Multiple handlers can be registered for specific exception types
🧪 Testability – Handlers are easier to unit test in isolation
🎯 Consistency – Uniform error responses across your API

This aligns perfectly with the Clean Architecture principle of separation of concerns — where exception management is isolated from business logic.

Setting Up the Project

Let’s start by creating a new Web API project and configuring global exception handling.

1. Project Configuration

Having set up our project, let’s now add the GlobalExceptionHandler class which implements IExceptionHandler:

public class CustomExceptionHandler: IExceptionHandler
{
}

Then, let’s register our exception handler in the dependency injection container:

builder.Services.AddExceptionHandler<CustomExceptionHandler>();
builder.Services.AddProblemDetails();

Whenever there’s an exception in our application, the GlobalExceptionHandler handler will be automatically invoked. The API will also generate ProblemDetails standardized responses as per RFC 7807 specification. This way, we have more control over how we intercept, handle, and format error responses.

Finally, let’s add the middleware to the application request pipeline:

app.UseExceptionHandler();

Now, let’s proceed to handle exceptions.

Let’s add a custom implementation of TryHandleAsync() method in our middleware:

 public async ValueTask<bool> TryHandleAsync(HttpContext context, Exception exception, CancellationToken cancellationToken)
 {
     int statusCode = exception switch
     {
         UnauthorizedAccessException => StatusCodes.Status401Unauthorized,
         ArgumentException => StatusCodes.Status400BadRequest,
         _ => StatusCodes.Status500InternalServerError
     };
     context.Response.StatusCode = statusCode;

     var problemDetails = new ProblemDetails
     {
         Status = statusCode,
         Title = “An error occurred”,
         Type = exception.GetType().Name,
         Detail = exception.Message,
         Instance = context.Request.Path
     };

     await context.Response.WriteAsJsonAsync(problemDetails, cancellationToken);

     return true;
 }

Let’s add an endpoint in the Program class to test this:

app.MapGet("/", () => "Hello World!");


// Example endpoint that throws an exception
app.MapGet("/error", () =>
{
    throw new Exception("This is a test exception!");
});

Calling the endpoint, the application throws a Exception exception.

Let’s test this out:

{
  "type": "Exception",
  "title": "An error occurred",
  "status": 500,
  "detail": "This is a test exception!",
  "instance": "/error"
}

🏁 Conclusion

The IExceptionHandler interface in .NET 8 provides a clean, testable, and extensible foundation for global exception handling.

By implementing it, you can:

• Centralize and simplify your error handling logic

• Deliver consistent, secure, and meaningful error responses

• Easily extend handling for specific exception types

• Improve maintainability, readability, and test coverage

In short, this feature is a game-changer for API resilience and a step toward cleaner architecture in modern .NET applications.

💬 Final Thought

If you haven’t yet tried IExceptionHandler, it’s a great opportunity to refactor your error handling strategy and align with the best practices of .NET 8.
A little investment in this pattern goes a long way in improving reliability and developer experience.

👉 Full working code available at:

🔗https://sourcecode.kanaiyakatarmal.com/GlobalErrorHandling

I hope you found this guide helpful and informative.

Thanks for reading!

If you enjoyed this article, feel free to share it and follow me for more practical, developer-friendly content like this.

What is the Adapter Design Pattern?

The Adapter Pattern is a structural design pattern that allows objects with incompatible interfaces to collaborate. Essentially, it converts the interface of a class into another interface that the client expects.

• Purpose: Allow incompatible interfaces to work together without changing their source code.

• Also Known As: Wrapper.

• Category: Structural pattern.

When to Use the Adapter Pattern

Use the Adapter Pattern when:

1. You want to integrate a class with an existing system but its interface is incompatible.

2. You want to reuse an existing class but need to adapt it to a new interface.

3. You aim to decouple code and make it more flexible and maintainable.

Structure of Adapter Pattern

The Adapter Pattern generally involves the following components:

1. Target – Defines the domain-specific interface that the client uses.

2. Client – Collaborates with objects conforming to the Target interface.

3. Adaptee – The existing class with an incompatible interface.

4. Adapter – Converts the interface of the Adaptee into the Target interface expected by the Client.

Client → Target → Adapter → Adaptee

C# Example of Adapter Pattern

Imagine we have an old legacy logging system and a new system that expects a different interface.

Step 1: Define the Target Interface

public interface ILogger
{
    void Log(string message);
}

Step 2: Existing Class (Adaptee)

public class LegacyLogger
{
    public void WriteLog(string logMessage)
    {
        Console.WriteLine($”Legacy log: {logMessage}”);
    }
}

Step 3: Create the Adapter

public class LoggerAdapter : ILogger
{
    private readonly LegacyLogger _legacyLogger;

    public LoggerAdapter(LegacyLogger legacyLogger)
    {
        _legacyLogger = legacyLogger;
    }

    public void Log(string message)
    {
        _legacyLogger.WriteLog(message); // Adapted call
    }
}

Step 4: Using the Adapter

class Program
{
    static void Main(string[] args)
    {
        LegacyLogger legacyLogger = new LegacyLogger();
        ILogger logger = new LoggerAdapter(legacyLogger);

        logger.Log(”Adapter pattern in action!”);
    }
}

Output:

Legacy log: Adapter pattern in action!

Here, the LoggerAdapter bridges the gap between the ILogger interface and the LegacyLogger class.

Benefits of Adapter Pattern

• Promotes code reuse without modifying existing code.

• Enhances flexibility by decoupling client code from specific implementations.

• Makes it easier to integrate third-party libraries.

Real-World Examples

1. Connecting new payment gateways to legacy e-commerce systems.

2. Adapting different file format readers in a document management system.

3. Bridging old APIs with modern service-oriented architectures.

Conclusion

The Adapter Design Pattern is a simple yet powerful solution to interface incompatibility problems. By using it in C#, you can integrate legacy systems, third-party libraries, or any incompatible components seamlessly while keeping your code clean and maintainable.

💬 Have you ever used the Adapter Pattern in a real project? What challenges did it help you solve?

👉 Full working code available at:

🔗https://sourcecode.kanaiyakatarmal.com/AdapterDesignPattern

I hope you found this guide helpful and informative.

Thanks for reading!

If you enjoyed this article, feel free to share it and follow me for more practical, developer-friendly content like this.

⚡ TL;DR (Two-line summary)

Use a layered approach:
➡ In-process cache for ultra-fast reads
➡ Distributed cache (Redis) for shared scale
➡ Versioning + invalidation + observability for correctness and reliability

1. Why Multi-layer Caching?

Caching isn’t one-size-fits-all. Different layers serve different needs.

• 🕐 Latency: In-process caches (IMemoryCache) return data in microseconds.

• 🌍 Scale & consistency: Distributed caches (Redis) let multiple app instances share state.

• 💰 Cost: Cache hot paths, not everything — protect the DB from expensive reads.

• ⚙️ Flexibility: Different access patterns require different cache semantics.

2. Cache layers roles & choices

a) In-process (local) cache

• Use for per-instance hot items (computed values, config).

• .NET: IMemoryCache (Microsoft.Extensions.Caching.Memory).

• Fast, but not shared across instances.

b) Distributed cache

• Use for shared data between instances (user sessions, product catalogs).

• Options: Redis (common), Memcached (less common for modern .NET), Azure Cache for Redis.

• .NET: IDistributedCache abstraction or direct client (StackExchange.Redis) for advanced scenarios.

c) CDN / edge caches

• For static assets and HTTP responses (images, HTML fragments).

• Useful for public-facing read-heavy endpoints.

d) Application-level output/response caching

• Use Response Caching, Output Caching or Varnish in front.

• In .NET: ResponseCaching middleware or ASP.NET Core Output Caching.

3. Caching Patterns in Action

Let’s use the new HybridCache introduced in .NET 8+ to illustrate core caching patterns.

Here’s a simple setup:

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; } = string.Empty;
    public decimal Price { get; set; }
}

public class ProductRepository
{
    private readonly Dictionary<int, Product> _db = new();

    public ProductRepository()
    {
        _db[1] = new Product { Id = 1, Name = “Laptop”, Price = 1200 };
        _db[2] = new Product { Id = 2, Name = “Phone”, Price = 800 };
    }

    public Task<Product?> GetByIdAsync(int id)
    {
        _db.TryGetValue(id, out var product);
        Console.WriteLine($”[DB] Get Product {id}”);
        return Task.FromResult(product);
    }

    public Task UpdateAsync(Product product)
    {
        _db[product.Id] = product;
        Console.WriteLine($”[DB] Updated Product {product.Id}”);
        return Task.CompletedTask;
    }
}

Cache Service

public class HybridCacheService
{
    private readonly HybridCache cache;
    private readonly ProductRepository repository;

    public HybridCacheService(HybridCache cache, ProductRepository repository)
    {
        this.cache = cache;
        this.repository = repository;
    }

    #region 1. Cache-Aside (Lazy Loading)
    public async Task<Product?> GetProductCacheAsideAsync(int id)
    {
        string cacheKey = $”Product_{id}”;

        return await cache.GetOrCreateAsync(
            cacheKey,
            async token => await repository.GetByIdAsync(id),
            new HybridCacheEntryOptions { Expiration = TimeSpan.FromMinutes(10) });
    }
    #endregion

    #region 2. Read-Through
    public async Task<Product?> GetProductReadThroughAsync(int id)
    {
        string cacheKey = $”Product_{id}”;

        return await cache.GetOrCreateAsync(
            cacheKey,
            async token => await repository.GetByIdAsync(id),
            new HybridCacheEntryOptions { Expiration = TimeSpan.FromMinutes(10) });
    }
    #endregion

    #region 3. Write-Around
    public async Task UpdateProductWriteAroundAsync(Product product)
    {
        // Write directly to DB only
        await repository.UpdateAsync(product);

        // Cache not updated
        Console.WriteLine(”[Cache-Write-Around] Skipped cache update”);
    }
    #endregion

    #region 4. Write-Back (Write-Behind)
    public async Task UpdateProductWriteBackAsync(Product product)
    {
        string cacheKey = $”Product_{product.Id}”;

        // Update cache first
        await cache.SetAsync(cacheKey, product, new HybridCacheEntryOptions
        {
            Expiration = TimeSpan.FromMinutes(10)
        });

        Console.WriteLine(”[Cache-Write-Back] Updated cache, DB async”);

        // Simulate background DB update
        _ = Task.Run(async () => await repository.UpdateAsync(product));
    }
    #endregion

    #region 5. Write-Through
    public async Task UpdateProductWriteThroughAsync(Product product)
    {
        string cacheKey = $”Product_{product.Id}”;

        // Update DB first
        await repository.UpdateAsync(product);

        // Update cache immediately
        await cache.SetAsync(cacheKey, product, new HybridCacheEntryOptions
        {
            Expiration = TimeSpan.FromMinutes(10)
        });

        Console.WriteLine(”[Cache-Write-Through] Updated cache & DB”);
    }
    #endregion
}

4. Caching patterns (when to use which)

Cache-Aside (lazy loading)

1. App checks cache.

2. On miss, load from DB, store in cache, then return.

• Pros: simple, explicit control.

• Cons: potential stampede on high-concurrency misses.

Read-Through / Write-Through

• Cache client (or a library) automatically fetches or writes through to backing store.

• Better for centralizing caching logic; often used in distributed caches with middleware.

Write-Behind (async write-back)

• Writes first to cache, then asynchronously to DB.

• Use cautiously: risk of data loss on crashes.

Write-Around Caching

• Avoid polluting the cache with data that may not be read soon after writing.

4. Consistency & Invalidation Strategies

Consistency is often harder than caching itself. Choose your invalidation model wisely:

• ⏰ Time-based TTL: Simple expiration; best for mostly-read or eventually consistent data.

• 🔄 Event-driven invalidation: Publish Redis Pub/Sub or message-bus events on data change.

• 🧩 Versioned keys: Add a version suffix — product:123:v42 — to invalidate old entries.

• 🎯 Partial invalidation: Invalidate specific keys instead of global cache flushes.

5. Preventing Cache Stampede (a.k.a. Thundering Herd)

When multiple requests miss the cache simultaneously:

• 🔒 Use distributed locks (e.g., Redis RedLock).

• 🚦 Apply the Singleflight pattern to deduplicate concurrent requests.

• 🔁 Implement in-flight caching — reuse in-progress tasks for the same key.

6. Key Design & Serialization

• Use predictable, readable keys like product:{id}:detail:v3.

• Avoid embedding JSON into keys.

• Use MessagePack or protobuf for large objects.

• Compress only if your payloads are big enough to justify CPU cost.

7. Security & Operational Considerations

• 🔐 Don’t cache sensitive/PII data unless encrypted.

• 🌍 Keep Redis close to your app (same region).

• 🧮 Tune Redis eviction policies (volatile-lru, allkeys-lru, etc.).

• 📊 Monitor IMemoryCache size and Redis memory usage.

• 🧠 Always track hit/miss ratios and latency metrics.

8. Observability & Metrics

Monitor your caching layer like a first-class system component:

• Cache hit/miss rate (overall & per key group)

• Average latency for Get and Set operations

• Evictions and expiration events

• Redis connection health and timeout rates

• Export metrics to Prometheus or Application Insights

9. Local Development & Testability

• Use in-memory cache or local Redis for testing.

• Abstract caching behind an ICacheService interface for mocks.

• Unit-test both cache-hit and cache-miss cases.

✅ Takeaways

Caching is more than just speed — it’s about data correctness, resilience, and cost-efficiency.

✔ Start simple — use IMemoryCache for fast local reads.
✔ Add a distributed cache (Redis / HybridCache) for scale.
✔ Implement proper invalidation and observability early.
✔ Evolve your cache strategy as your traffic and data patterns grow.

❓What Do You Think?

Caching can make or break your system’s performance - so I’m curious:

👉 Which caching mistake or pattern has caused you the most trouble (or biggest win) in your .NET projects?

Share your thoughts or war stories in the comments, I’d love to hear how you’ve handled caching in production.

👉 Full working code available at:

🔗https://sourcecode.kanaiyakatarmal.com/HybridCache

I hope you found this guide helpful and informative.

Thanks for reading!

If you enjoyed this article, feel free to share it and follow me for more practical, developer-friendly content like this.

But what if you have multiple implementations of the same interface — like Email, SMS, and Push notifications — and you need to decide which one to use at runtime?

That’s where Keyed Services, introduced in .NET 8, come to the rescue.

🧩 The Problem Before Keyed Services

Imagine you have an interface:

public interface INotificationService
{
    void Send(string message);
}

And you have multiple implementations:

public class EmailNotificationService : INotificationService
{
    public void Send(string message)
        => Console.WriteLine($”Email: {message}”);
}

public class SmsNotificationService : INotificationService
{
    public void Send(string message)
        => Console.WriteLine($”SMS: {message}”);
}

public class PushNotificationService : INotificationService
{
    public void Send(string message)
        => Console.WriteLine($”Push: {message}”);
}

Before .NET 8, registering all these in DI meant you had to inject them as IEnumerable<INotificationService> and manually decide which one to use — not ideal.

🚀 Enter Keyed Services

With .NET 8, you can now register services with keys and inject them directly by key.
Here’s how it looks in code:

builder.Services.AddKeyedSingleton<INotificationService,SmsNotificationService>("sms");
builder.Services.AddKeyedSingleton<INotificationService,EmailNotificationService>("email");
builder.Services.AddKeyedSingleton<INotificationService,PushNotificationService>("push");

Each service registration is now associated with a unique key — “sms”, “email”, and “push”.

💉 Injecting Keyed Services

Once registered, you can inject the specific implementation using the [FromKeyedServices] attribute:

public class NotificationHandler
{
    private readonly INotificationService _emailService;
    private readonly INotificationService _smsService;
    private readonly INotificationService _pushService;

    public NotificationHandler(
        [FromKeyedServices(”email”)] INotificationService emailService,
        [FromKeyedServices(”sms”)] INotificationService smsService,
        [FromKeyedServices(”push”)] INotificationService pushService)
    {
        _emailService = emailService;
        _smsService = smsService;
        _pushService = pushService;
    }

    public void NotifyAll()
    {
        _emailService.Send(”📧 Sending Email Notification”);
        _smsService.Send(”📱 Sending SMS Notification”);
        _pushService.Send(”🔔 Sending Push Notification”);
    }
}

No more manual filtering or loops — just clean, declarative dependency injection.

⚙️ Manual Resolution (Optional)

If you ever need to resolve a keyed service manually, you can use:

var smsService = provider.GetKeyedService<INotificationService>(”sms”);
smsService?.Send(”Manual SMS Notification”);

This is useful in factories, background jobs, or middleware where constructor injection isn’t practical.

💡 When to Use Keyed Services

✅ You have multiple strategies or implementations (like different payment, cache, or logging providers).
✅ You want to choose implementations explicitly without complex factory logic.
✅ You prefer strong typing over string-based condition checks.

⚠️ When Not to Use It

❌ If you only have one implementation — regular AddSingleton or AddTransient is simpler.
❌ If runtime selection depends on dynamic conditions — a factory pattern may still be more flexible.
❌ Overusing keys can make DI harder to trace — use thoughtfully.

🧠 Bonus: Keyed Generics

Keyed services also support generic registrations:

builder.Services.AddKeyedScoped(typeof(IRepository<>), typeof(SqlRepository<>), “sql”);
builder.Services.AddKeyedScoped(typeof(IRepository<>), typeof(MongoRepository<>), “mongo”);

And you can inject them just like before:

public class DataSyncService
{
    private readonly IRepository<Customer> _sqlRepo;

    public DataSyncService([FromKeyedServices(”sql”)] IRepository<Customer> sqlRepo)
    {
        _sqlRepo = sqlRepo;
    }
}

🏁 Final Thoughts

Keyed Services are one of the most practical additions in .NET 8’s DI system.
They make it easier to handle multiple implementations of the same interface — without messy filtering logic or custom factories.

So the next time you’re juggling different strategies — whether it’s Email, SMS, or Push — remember:
A well-chosen key can make your dependencies cleaner and smarter.

👉 Full working code available at:

🔗https://sourcecode.kanaiyakatarmal.com/KeyedServices

I hope you found this guide helpful and informative.

Thanks for reading!

If you enjoyed this article, feel free to share it and follow me for more practical, developer-friendly content like this.

Circuit breakers protect your application from repeated failures by temporarily blocking calls to a failing service and allowing it to recover. In ASP.NET Core, you can implement this pattern seamlessly using Polly and the Microsoft.Extensions.Http.Resilience package.

What is a Circuit Breaker?

The Circuit Breaker pattern is inspired by electrical circuit breakers: it prevents an application from repeatedly trying to execute an operation that is likely to fail.

• Closed state: Requests flow normally.

• Open state: Requests fail immediately without hitting the failing service.

• Half-open state: After a defined interval, a few requests are allowed to test if the service has recovered.

In short, a circuit breaker “breaks” the circuit when failures exceed a threshold and prevents your application from overloading a struggling service.

Why Use a Circuit Breaker?

Using a circuit breaker in your applications provides multiple benefits:

1. Improved Resilience: Prevents cascading failures when downstream services are unavailable or slow.

2. Fail Fast: Instead of waiting for timeouts on failing services, requests fail immediately when the circuit is open.

3. System Stability: Protects your resources (threads, memory) from being overwhelmed by repeated failures.

4. Graceful Degradation: Gives your application time to recover or fallback to alternative flows.

5. Operational Insights: Monitoring circuit states helps detect failing services early.

In this article, we’ll explore how to implement the Cache-Aside pattern in .NET Core 9 using HybridCache, which supports both in-memory and Redis caching.

Setting Up a Circuit Breaker in ASP.NET Core

First, add the required NuGet packages for caching:

dotnet add package Microsoft.Extensions.Http.Resilience

In ASP.NET Core, you can implement the Circuit Breaker pattern easily using Microsoft.Extensions.Http.Resilience. Here’s a sample configuration:

// Add HttpClient with Circuit Breaker
builder.Services.AddHttpClient("ExternalApiClient")
    .AddResilienceHandler("circuit-breaker-pipeline", builder =>
    {
        builder.AddCircuitBreaker(new HttpCircuitBreakerStrategyOptions
        {
            FailureRatio = 0.1,       // 10% failure ratio triggers the circuit
            MinimumThroughput = 10,   // Minimum number of requests before evaluation
            SamplingDuration = TimeSpan.FromSeconds(30),
            BreakDuration = TimeSpan.FromSeconds(15) // Open circuit for 15 seconds
        });
    });

Using the Circuit Breaker in Controllers

After configuring the HttpClient, you can use it in your controller:

namespace CircuitBreakerApi.Controllers
{
    using Microsoft.AspNetCore.Mvc;
    using System.Net.Http;
    using System.Threading.Tasks;

    [ApiController]
    [Route("[controller]")]
    public class ExternalApiController : ControllerBase
    {
        private readonly IHttpClientFactory _httpClientFactory;

        public ExternalApiController(IHttpClientFactory httpClientFactory)
        {
            _httpClientFactory = httpClientFactory;
        }

        [HttpGet("data")]
        public async Task<IActionResult> GetExternalData()
        {
            var client = _httpClientFactory.CreateClient("ExternalApiClient");

            try
            {
                var response = await client.GetAsync("https://jsonplaceholder.typicode.com/todos/1");

                if (response.IsSuccessStatusCode)
                {
                    var data = await response.Content.ReadAsStringAsync();
                    return Ok(data);
                }
                else
                {
                    return StatusCode((int)response.StatusCode, "External API failed");
                }
            }
            catch (Exception ex)
            {
                // Circuit breaker will throw if the circuit is open
                return StatusCode(503, $"Request failed: {ex.Message}");
            }
        }
    }
}

How It Works

1. Monitoring: The circuit breaker monitors requests and tracks failures.

2. Breaking: If failures exceed the threshold, the circuit opens, preventing further requests to the failing service.

3. Recovery: After a break duration, the circuit enters half-open, allowing a few requests to check if the service has recovered.

4. Closing: If the service responds successfully, the circuit closes, and normal traffic resumes.

Benefits Recap

• Better user experience: Avoid long waits and timeouts for end users.

• Resource protection: Prevent threads, memory, and CPU from being exhausted.

• Faster failure detection: Immediate awareness when downstream services fail.

• Resilient systems: Helps maintain overall application stability.

Engaging Thought:
Have you ever noticed your app slowing down because an external API was failing? Imagine how a circuit breaker could have stopped that cascade—how would your system behave differently under failure?

👉 Full working code available at:

🔗https://sourcecode.kanaiyakatarmal.com/CircuitBreaker

I hope you found this guide helpful and informative.

Thanks for reading!

If you enjoyed this article, feel free to share it and follow me for more practical, developer-friendly content like this.

In this article, we’ll explore how to implement the Cache-Aside pattern in .NET Core 9 using HybridCache, which supports both in-memory and Redis caching.

Why Cache-Aside?

The Cache-Aside pattern works like this:

1. Your application tries to read data from the cache.

2. If the data exists, return it immediately (cache hit).

3. If the data doesn’t exist (cache miss), fetch it from the database.

4. Store the fetched data in the cache for subsequent requests.

This approach is highly flexible because your cache doesn’t need to be kept in sync automatically with the database, it’s updated only when necessary.

Setting Up the Project

First, add the required NuGet packages for caching:

dotnet add package Microsoft.Extensions.Caching.Hybrid
dotnet add package Microsoft.Extensions.Caching.StackExchangeRedis

We'll use HybridCache for managing cache across memory and Redis seamlessly.

Creating the Product Entity

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
    public string SKU { get; set; }
}

This is a simple Product entity for demonstration purposes.

Creating the Repository and Service Layer

We’ll define a repository interface to interact with the database and a service layer for caching logic.

IProductService.cs

using CacheStrategiesSample.Data;
using System.Collections.Generic;
using System.Threading.Tasks;

public interface IProductService
{
    Task<Product?> GetByIdAsync(int id);
}

ProductService.cs

using CacheStrategiesSample.Data;
using CacheStrategiesSample.Repository;
using Microsoft.Extensions.Caching.Hybrid;
using System.Collections.Generic;
using System.Threading.Tasks;

public class ProductService : IProductService
{
    private readonly IRepository<Product> _productRepository;
    private readonly HybridCache _cache;

    public ProductService(IRepository<Product> productRepository, HybridCache cache)
    {
        _productRepository = productRepository;
        _cache = cache;
    }

    public async Task<Product?> GetByIdAsync(int id)
    {
        string cacheKey = $"Product_{id}";
        var product = await _cache.GetOrCreateAsync<Product?>(cacheKey, async _ =>
        {
            // Fetch from repository if not in cache
            return await _productRepository.GetByIdAsync(id);
        });
        return product;
    }

  
}

Notice how the GetByIdAsync method handles caching. It first checks the cache and falls back to the repository if needed. This is the essence of the Cache-Aside pattern.

Creating the API Controller

using CacheStrategiesSample.Data;
using CacheStrategiesSample.Services;
using Microsoft.AspNetCore.Mvc;
using System.Threading.Tasks;

[ApiController]
[Route("api/[controller]")]
public class ProductController : ControllerBase
{
    private readonly IProductService _productService;

    public ProductController(IProductService productService)
    {
        _productService = productService;
    }
   
    [HttpGet("{id}")]
    public async Task<IActionResult> GetById(int id)
    {
        var product = await _productService.GetByIdAsync(id);
        if (product == null) return NotFound();
        return Ok(product);
    }
   
}

With this setup, every request to GetById first checks the cache, reducing database load and improving response time.

Benefits of Using HybridCache

• Seamless multi-level caching: In-memory + Redis.

• Automatic key expiration: Avoid stale data.

• Simple API: GetOrCreateAsync makes cache-aside implementation almost trivial.

• Flexible storage: Switch or combine cache providers without changing business logic.

Conclusion

Implementing the Cache-Aside pattern in .NET Core 9 is straightforward with HybridCache. By combining repository-based data access with caching, you can dramatically improve your application’s performance, reduce database load, and maintain flexibility in your caching strategy.

This pattern is especially useful for high-traffic APIs where database hits are expensive and response speed matters.

🌟 Have you ever experienced a performance boost just by adding caching to your application? What strategy worked best for you?

👉 Full working code available at:

🔗https://sourcecode.kanaiyakatarmal.com/CacheStrategiesSample

I hope you found this guide helpful and informative.

Thanks for reading!

If you enjoyed this article, feel free to share it and follow me for more practical, developer-friendly content like this.