Forem: Libin Tom Baby

How Dependency Injection Works Internally in .NET

Libin Tom Baby — Wed, 15 Apr 2026 14:00:00 +0000

ServiceCollection, IServiceProvider, resolution chain, scope factory, how the container builds the object graph

Every ASP.NET Core application uses dependency injection.

But most developers only know how to use it — not how the container actually works under the hood.

This guide explains the mechanics: how services are registered, how the container resolves them, how lifetimes are enforced, and the mistakes that silently break things.

The Three Building Blocks

1. `IServiceCollection` — the registration

IServiceCollection is just a list. When you call AddScoped<T>(), you're adding a ServiceDescriptor to that list.

builder.Services.AddSingleton<ILogger, Logger>();
builder.Services.AddScoped<IUserService, UserService>();
builder.Services.AddTransient<IEmailService, EmailService>();

Nothing is created yet. You're just declaring what to build.

2. `IServiceProvider` — the container

When .Build() is called, the IServiceCollection is compiled into an IServiceProvider — the actual DI container.

var app = builder.Build(); // IServiceProvider is created here

3. Resolution — how objects are constructed

When a service is requested, the container:

Looks up the registered ServiceDescriptor
Checks if an existing instance should be returned (singleton/scoped)
If not, creates a new instance using the registered constructor
Resolves all constructor dependencies recursively
Returns the fully-constructed object

The Three Lifetimes — Explained Internally

Singleton

builder.Services.AddSingleton<IConfigService, ConfigService>();

One instance created on first request. Stored in the root container. Returned for every subsequent request — forever.

Use for: stateless services, configuration, caches, HTTP clients.

Scoped

builder.Services.AddScoped<IDbContext, AppDbContext>();

One instance per HTTP request. Created when the scope starts, disposed when it ends.

In ASP.NET Core, a new IServiceScope is created for each HTTP request. All scoped services within that request share the same instance.

Use for: database contexts, unit-of-work, per-request state.

Transient

builder.Services.AddTransient<IEmailService, EmailService>();

A new instance every single time the service is requested. No sharing.

Use for: lightweight, stateless services where a fresh instance is always needed.

How Constructor Injection Works

The container uses reflection to inspect the constructor.

public class OrderService
{
    private readonly IDbContext _db;
    private readonly IEmailService _email;
    private readonly ILogger<OrderService> _logger;

    public OrderService(
        IDbContext db,
        IEmailService email,
        ILogger<OrderService> logger)
    {
        _db = db;
        _email = email;
        _logger = logger;
    }
}

When IOrderService is requested, the container:

Finds OrderService as the implementation
Inspects its constructor via reflection
Resolves IDbContext, IEmailService, and ILogger<OrderService> recursively
Creates the OrderService instance with all dependencies injected

If any dependency is not registered, an InvalidOperationException is thrown at resolution time.

The Captive Dependency Problem

The most dangerous lifetime mistake.

A singleton depending on a scoped service:

// ❌ Captive dependency — runtime exception or silent bug
public class ReportService // Singleton
{
    public ReportService(IDbContext db) { } // IDbContext is Scoped
}

A singleton lives forever. A scoped service is tied to a request. The scoped service is never released — it becomes effectively a singleton with incorrect state.

ASP.NET Core detects this in Development mode. Enable it explicitly in Production:

builder.Host.UseDefaultServiceProvider(options =>
{
    options.ValidateScopes = true;
    options.ValidateOnBuild = true;
});

Resolving Services Manually

// From IServiceProvider directly
var service = app.Services.GetRequiredService<IMyService>();

// Creating a scope manually (e.g. in a background service)
using var scope = app.Services.CreateScope();
var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
await db.SaveChangesAsync();

Never resolve scoped services from the root IServiceProvider — they won't be disposed correctly. Always create a scope first.

Interview-Ready Summary

IServiceCollection is just a list of descriptors — nothing is created at registration
IServiceProvider is the compiled container that resolves and creates objects
Resolution works by inspecting constructors via reflection and recursively resolving dependencies
Singleton = one instance forever; Scoped = one per request; Transient = always new
Captive dependency = singleton holding a scoped service — causes bugs or exceptions
Always use CreateScope() when resolving scoped services in background contexts
ValidateOnBuild = true catches registration errors at startup, not at runtime

A strong interview answer:

"The .NET DI container is built from IServiceCollection — a list of service registrations. At build time, it compiles into an IServiceProvider. When a service is requested, the container uses reflection to inspect the constructor, recursively resolves each dependency, respects lifetimes, and returns the fully constructed object. The main lifetime trap is the captive dependency — a singleton holding a scoped service, which prevents proper disposal."

The Middleware Pipeline in ASP.NET Core — How It Really Works

Libin Tom Baby — Mon, 13 Apr 2026 14:00:00 +0000

Use, Run, Map, short-circuit, ordering, custom middleware

Every HTTP request in ASP.NET Core passes through a pipeline of middleware components before reaching your controller.

Understanding this pipeline is essential — it's where logging, authentication, exception handling, CORS, routing, and response caching all live.

What Is Middleware?

Middleware is software assembled into a pipeline to handle requests and responses.

Each middleware component:

Receives the incoming HttpContext
Optionally does something with the request
Calls the next middleware in the chain
Optionally does something with the response on the way back

Request  → [Logging] → [Auth] → [CORS] → [Routing] → [Handler]
Response ← [Logging] ← [Auth] ← [CORS] ← [Routing] ← [Handler]

The Three Methods: Use, Run, Map

`Use` — calls the next component

app.Use(async (context, next) =>
{
    Console.WriteLine("Before next middleware");
    await next(context);
    Console.WriteLine("After next middleware");
});

`Run` — terminal, does NOT call next

app.Run(async context =>
{
    await context.Response.WriteAsync("Hello — pipeline stops here");
});

`Map` — branches based on path

app.Map("/health", branch =>
{
    branch.Run(async context =>
    {
        await context.Response.WriteAsync("Healthy");
    });
});

Ordering Matters — A Lot

The order you register middleware is the order it runs.

app.UseExceptionHandler();    // 1 — catch all unhandled exceptions first
app.UseHttpsRedirection();    // 2
app.UseCors();                // 3
app.UseAuthentication();      // 4 — who are you?
app.UseAuthorization();       // 5 — what can you do?
app.UseRateLimiter();         // 6
app.MapControllers();         // 7 — route to controller

Getting the order wrong causes real bugs. Authentication before exception handling means auth errors won't be caught cleanly.

Short-Circuiting the Pipeline

Middleware can stop the request from proceeding further.

app.Use(async (context, next) =>
{
    if (!context.Request.Headers.ContainsKey("X-API-Key"))
    {
        context.Response.StatusCode = 401;
        await context.Response.WriteAsync("Missing API key");
        return; // ← Does NOT call next — pipeline stops here
    }

    await next(context);
});

This is how authentication middleware works — validate the token, let through or short-circuit with 401.

Building Custom Middleware

Inline (simple cases)

app.Use(async (context, next) =>
{
    context.Response.Headers.Add("X-Custom-Header", "MyApp");
    await next(context);
});

Class-based (preferred for complex middleware)

public class RequestTimingMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<RequestTimingMiddleware> _logger;

    public RequestTimingMiddleware(RequestDelegate next, ILogger<RequestTimingMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        var stopwatch = Stopwatch.StartNew();

        await _next(context);

        stopwatch.Stop();
        _logger.LogInformation(
            "Request {Method} {Path} completed in {ElapsedMs}ms",
            context.Request.Method,
            context.Request.Path,
            stopwatch.ElapsedMilliseconds);
    }
}

// Extension method
public static class RequestTimingMiddlewareExtensions
{
    public static IApplicationBuilder UseRequestTiming(this IApplicationBuilder app)
        => app.UseMiddleware<RequestTimingMiddleware>();
}

// Usage
app.UseRequestTiming();

Real-World Scenarios

Logging every request and response

app.Use(async (context, next) =>
{
    _logger.LogInformation("Incoming: {Method} {Path}",
        context.Request.Method, context.Request.Path);

    await next(context);

    _logger.LogInformation("Outgoing: {StatusCode}",
        context.Response.StatusCode);
});

Adding a correlation ID to every response

app.Use(async (context, next) =>
{
    context.Response.Headers.Add("X-Correlation-Id", Guid.NewGuid().ToString());
    await next(context);
});

Interview-Ready Summary

Middleware forms a bidirectional pipeline — request goes in, response comes back
Use = calls next, Run = terminal, Map = branch by path
Order of registration = order of execution
Short-circuiting stops the pipeline — used by auth, rate limiting, validation
Custom middleware goes in a class implementing InvokeAsync(HttpContext)
Exception handling middleware should be first (outermost) so it catches everything

A strong interview answer:

"ASP.NET Core middleware forms a pipeline where each component can process the request before passing it to the next, and then process the response on the way back. The order matters — exception handling goes first, then CORS, then authentication, then routing. You can short-circuit the pipeline at any point, which is how auth middleware rejects unauthorised requests."

Threading vs Tasks vs Parallelism — The Complete .NET Concurrency Guide

Libin Tom Baby — Sat, 11 Apr 2026 14:00:00 +0000

Thread, ThreadPool, Task, Parallel.For, PLINQ, when to use each

Concurrency is one of the most misunderstood areas of .NET development.

Thread, Task, Parallel, async/await — developers often use these interchangeably without understanding what they actually do. The wrong choice costs you performance, correctness, and scalability.

This guide breaks down each concept clearly, with real-world guidance on when to use which.

⚠️ Note: Another post Async/Await in C# — A Deep Dive Into How Asynchronous Programming Really Works covers the difference between asynchrony and parallelism briefly. This post goes much deeper into the underlying primitives — Thread, ThreadPool, Task, and Parallel.

The Mental Model

Before the code, get the mental model right.

Concurrency — dealing with multiple things at once (managing)
Parallelism — doing multiple things at once (executing)
Asynchrony — starting something and doing other work while waiting

These are not the same thing.

Thread — The Low-Level Primitive

A Thread is an OS-level execution unit.

var thread = new Thread(() =>
{
    Console.WriteLine($"Running on thread {Thread.CurrentThread.ManagedThreadId}");
});

thread.Start();
thread.Join(); // Wait for it to finish

What you get

Full control over the thread lifecycle
Can set priority, name, apartment state
Can be a foreground or background thread

What it costs

Creating a thread allocates ~1MB of stack memory
OS scheduling overhead on every context switch
You are responsible for lifecycle management
Does not integrate with async/await

When to use Thread directly

Almost never in modern .NET. Use Task instead.

The only remaining valid use case is COM interop requiring a specific apartment state (STA thread for WinForms/WPF dialogs).

ThreadPool — Reusing Threads

The ThreadPool manages a pool of pre-created threads that can be reused.

ThreadPool.QueueUserWorkItem(_ =>
{
    Console.WriteLine("Running on a pool thread");
});

You don't create threads — you submit work items and the pool decides which thread handles it.

Why this matters

No thread creation overhead
Threads are reused across work items
The runtime tunes the pool size automatically

When to use ThreadPool directly

You don't. Task.Run() wraps ThreadPool and gives you a much better API.

Task — The Modern Standard

Task is the recommended abstraction for concurrent and asynchronous work in .NET.

// CPU-bound work on the ThreadPool
var task = Task.Run(() =>
{
    return ExpensiveCalculation();
});

var result = await task;

Task represents a promise

A Task is a promise that work will complete at some point.

Task — work with no return value
Task<T> — work that returns a value
ValueTask<T> — lightweight Task for high-frequency paths

Combining Tasks

// Run two tasks in parallel and wait for both
var t1 = Task.Run(() => DoWork1());
var t2 = Task.Run(() => DoWork2());

await Task.WhenAll(t1, t2);

// Wait for the first one to finish
var winner = await Task.WhenAny(t1, t2);

async/await — Asynchrony Without Blocking

async/await is not about parallelism.

It is about freeing threads while waiting for I/O — network calls, database queries, file reads.

// The thread is released while waiting for the HTTP response
var response = await httpClient.GetAsync(url);

The critical distinction

Scenario	Use
Waiting for a database query	`async`/`await`
Waiting for an HTTP call	`async`/`await`
Running a heavy calculation	`Task.Run()`
Running multiple calculations at once	`Parallel.For` / `Task.WhenAll`

Parallel — True CPU Parallelism

Parallel splits work across multiple CPU cores simultaneously.

Parallel.For

Parallel.For(0, 1000, i =>
{
    ProcessItem(i);
});

Parallel.ForEach

var items = GetLargeCollection();

Parallel.ForEach(items, item =>
{
    Process(item);
});

PLINQ

var results = items
    .AsParallel()
    .Where(x => x.IsValid)
    .Select(x => Transform(x))
    .ToList();

When to use Parallel

Only for CPU-bound work that can be split into independent chunks.

Never use Parallel for I/O-bound work — it wastes threads and can cause thread starvation.

The Decision Framework

Is the work CPU-bound or I/O-bound?
│
├── I/O-bound (network, DB, file)
│   └── Use async/await
│       └── Task.Run is NOT needed here
│
└── CPU-bound (calculations, image processing)
    │
    ├── Single heavy operation
    │   └── Task.Run(() => HeavyWork())
    │
    └── Many independent items
        └── Parallel.For / Parallel.ForEach / PLINQ

Common Mistakes

Mistake 1: Using Task.Run for I/O-bound work

// ❌ Wrong — wastes a thread waiting for I/O
var result = await Task.Run(() => httpClient.GetAsync(url));

// ✅ Correct — no thread needed while waiting
var result = await httpClient.GetAsync(url);

Mistake 2: Using async/await for CPU-bound work

// ❌ Looks async but blocks the thread
public async Task<int> ComputeAsync()
{
    return HeavyCpuWork(); // No await — just pretending to be async
}

// ✅ Correct — offload to ThreadPool
public async Task<int> ComputeAsync()
{
    return await Task.Run(() => HeavyCpuWork());
}

Mistake 3: Parallel for I/O

// ❌ This spawns threads and blocks them all waiting for HTTP
Parallel.ForEach(urls, url =>
{
    var result = httpClient.GetAsync(url).Result; // Blocking!
});

// ✅ Use Task.WhenAll for parallel async I/O
var tasks = urls.Select(url => httpClient.GetAsync(url));
var results = await Task.WhenAll(tasks);

Interview-Ready Summary

Thread is the OS-level primitive — powerful but expensive and rarely needed directly
ThreadPool recycles threads — Task.Run wraps it
Task is the standard abstraction for concurrent work
async/await frees threads during I/O — it is not parallelism
Parallel.For / Parallel.ForEach distributes CPU work across cores
I/O-bound → async/await; CPU-bound single op → Task.Run; CPU-bound many items → Parallel
Never use Parallel for I/O — it wastes threads

A strong interview answer:

"Threads are the OS-level unit of execution — expensive to create. Tasks abstract over the ThreadPool and support async/await. Async/await is about freeing threads during I/O, not parallelism. Parallelism means actually executing work on multiple cores simultaneously — that's what Parallel.For and Task.WhenAll are for. The golden rule: async/await for I/O-bound, Parallel or Task.Run for CPU-bound."

IAsyncEnumerable Explained — Async Streams in .NET

Libin Tom Baby — Thu, 09 Apr 2026 14:00:00 +0000

IAsyncEnumerable, yield return, cancellation tokens, vs IEnumerable, real-world streaming

Most developers know IEnumerable<T> and async/await.

IEnumerable<T> — lets you iterate a sequence.

async/await — lets you do I/O without blocking threads.

But IAsyncEnumerable<T> — introduced in C# 8 — combines both, and it solves a problem that neither alone handles well.

It lets you iterate a sequence asynchronously — yielding items one at a time as they become available, without loading everything into memory first.

The Problem They Solve

Imagine reading 100,000 records from a database and returning them to the caller.

Option 1: Return everything at once

public async Task<List<Order>> GetAllOrdersAsync()
{
    return await db.Orders.ToListAsync(); // ❌ Loads everything into memory
}

Memory spikes. The caller waits for the entire load.

Option 2: Synchronous yield

public IEnumerable<Order> GetAllOrders()
{
    foreach (var order in db.Orders) // ❌ Blocks the thread
        yield return order;
}

Streams items one at a time, but blocks the thread on every read.

Option 3: IAsyncEnumerable — the right way

public async IAsyncEnumerable<Order> GetAllOrdersAsync()
{
    await foreach (var order in db.Orders.AsAsyncEnumerable())
        yield return order; // ✅ Non-blocking, streamed one at a time
}

Items are produced and consumed one at a time, without blocking the thread, without loading everything into memory.

How It Works

IAsyncEnumerable<T> is the async version of IEnumerable<T>.

How to Produce an Async Stream

Use async, return IAsyncEnumerable<T>, and yield return each item.

// Producer
public async IAsyncEnumerable<int> GenerateNumbersAsync()
{
    for (int i = 0; i < 10; i++)
    {
        await Task.Delay(100); // Simulates async work
        yield return i;
    }
}

The producer can await before yielding each item. Each call to yield return sends one item to the consumer, then pauses until the consumer requests the next one.

How to Consume an Async Stream

The consumer uses await foreach.

// Consumer
await foreach (var number in GenerateNumbersAsync())
{
    Console.WriteLine(number);
}

This is the async equivalent of foreach.

Each iteration awaits the next item without blocking the thread.

Cancellation Support

Always support cancellation in long-running async streams.

Producer with cancellation

public async IAsyncEnumerable<Order> GetOrdersAsync(
    [EnumeratorCancellation] CancellationToken ct = default)
{
    await foreach (var order in db.Orders.AsAsyncEnumerable().WithCancellation(ct))
    {
        yield return order;
    }
}

Consumer with cancellation

using var cts = new CancellationTokenSource(TimeSpan.FromSeconds(30));

await foreach (var order in GetOrdersAsync().WithCancellation(cts.Token))
{
    Process(order);
}

Without cancellation, a long-running stream can run indefinitely.

IAsyncEnumerable vs IEnumerable

	`IEnumerable<T>`	`IAsyncEnumerable<T>`
Execution	Synchronous	Asynchronous
Thread blocking	Yes	No
Use case	In-memory data	I/O-bound data sources
Iteration	`foreach`	`await foreach`
Cancellation	No	Yes (CancellationToken)
Memory	Can load all at once	Streams item by item

IAsyncEnumerable vs Task<List<T>>

	`Task<List<T>>`	`IAsyncEnumerable<T>`
Returns	All items at once	One at a time
Memory usage	High (all in memory)	Low (streaming)
Time to first item	After all items loaded	Immediately
Best for	Small datasets	Large or infinite streams

Real-World Scenarios

Scenario 1: Streaming database records

public async IAsyncEnumerable<Product> GetLowStockProductsAsync(
    [EnumeratorCancellation] CancellationToken ct = default)
{
    await foreach (var product in db.Products
        .Where(p => p.StockLevel < 10)
        .AsAsyncEnumerable()
        .WithCancellation(ct))
    {
        yield return product;
    }
}

Scenario 2: Streaming an external API

public async IAsyncEnumerable<WeatherReading> StreamWeatherAsync(
    [EnumeratorCancellation] CancellationToken ct = default)
{
    while (!ct.IsCancellationRequested)
    {
        var reading = await _weatherApi.GetLatestAsync(ct);
        yield return reading;
        await Task.Delay(1000, ct);
    }
}

Scenario 3: Reading a large file line by line

public async IAsyncEnumerable<string> ReadLinesAsync(
    string path,
    [EnumeratorCancellation] CancellationToken ct = default)
{
    await foreach (var line in File.ReadLinesAsync(path, ct))
    {
        yield return line;
    }
}

Scenario 4: Exposing async streams from an API endpoint (ASP.NET Core)

[HttpGet("stream")]
public async IAsyncEnumerable<Order> StreamOrders(
    [EnumeratorCancellation] CancellationToken ct)
{
    await foreach (var order in _service.GetOrdersAsync(ct))
    {
        yield return order;
    }
}

ASP.NET Core supports returning IAsyncEnumerable<T> directly from action methods.

Interview-Ready Summary

IAsyncEnumerable<T> lets you stream data asynchronously — one item at a time
Use yield return in an async method returning IAsyncEnumerable<T> to produce a stream
Use await foreach to consume it
Always use [EnumeratorCancellation] CancellationToken in producers
Use .WithCancellation(ct) in consumers
Prefer IAsyncEnumerable<T> over Task<List<T>> when datasets are large, unbounded, or I/O-bound
ASP.NET Core can return IAsyncEnumerable<T> directly from controller actions

A strong interview answer:

"IAsyncEnumerable allows asynchronous iteration — yielding items one at a time as they're available, instead of loading everything into memory first. It's ideal for large database queries, external API streams, and file processing. You produce it with yield return in an async method, and consume it with await foreach."

⭐ Add-On — LINQ and IAsyncEnumerable

As of .NET 9, LINQ supports IAsyncEnumerable<T> natively.

// .NET 9+
var filtered = await GetOrdersAsync()
    .Where(o => o.Amount > 100)
    .Take(50)
    .ToListAsync();

Before .NET 9, you needed the System.Linq.Async NuGet package for this.
Now it's built in — making async streams a first-class citizen alongside standard LINQ.

Record Types in C# — Immutability, Equality, and When to Use Them

Libin Tom Baby — Wed, 08 Apr 2026 07:15:43 +0000

record, record struct, init, with expressions, value equality

Record Types in C#

Records were introduced in C# 9 and enhanced in C# 10.

They look like classes. They behave differently.

Most developers use records without fully understanding what makes them special — and more importantly, when they're the right tool and when they're not.

This guide breaks down everything you need to know.

What is a Record?

A record is a reference type (like a class) that is designed for immutable data with value-based equality.

public record Person(string Name, int Age);

That one line gives you:

A constructor
Public init-only properties
ToString() override
Equals() and GetHashCode() based on values — not references
Deconstruction support
with expression support

Value Equality — The Core Difference

With a class, two objects are equal only if they are the same object in memory.

With a record, two objects are equal if their values are the same.

Class (reference equality)

var p1 = new PersonClass { Name = "Alice", Age = 30 };
var p2 = new PersonClass { Name = "Alice", Age = 30 };

Console.WriteLine(p1 == p2); // False — different objects in memory

Record (value equality)

var p1 = new Person("Alice", 30);
var p2 = new Person("Alice", 30);

Console.WriteLine(p1 == p2); // True — same values

This is the single most important thing to understand about records.

Immutability With `init`

Record properties use init accessors by default — they can only be set during construction.

var person = new Person("Alice", 30);
person.Name = "Bob"; // ❌ Compile error — init-only

This makes records safe to pass around without defensive copying.

The `with` Expression

You cannot mutate a record. But you can create a modified copy using with.

var original = new Person("Alice", 30);
var updated = original with { Age = 31 };

Console.WriteLine(original); // Person { Name = Alice, Age = 30 }
Console.WriteLine(updated);  // Person { Name = Alice, Age = 31 }

The original is untouched.
with creates a shallow copy with the specified properties replaced.

Deconstruction

Records support positional deconstruction automatically.

public record Person(string Name, int Age);

var person = new Person("Alice", 30);
var (name, age) = person;

Console.WriteLine(name); // Alice
Console.WriteLine(age);  // 30

Record vs Class — Feature Comparison

Feature	Record	Class
Type	Reference type	Reference type
Equality	Value-based	Reference-based
Immutability	`init` by default	Mutable by default
`with` expression	Yes	No
Inheritance	Supported	Supported
`ToString()`	Auto-generated	Default object.ToString()
Best for	DTOs, value objects, API responses	Entities, services, stateful objects

Record Struct (C# 10)

C# 10 introduced record struct — a value type record.

public record struct Point(double X, double Y);

var a = new Point(1.0, 2.0);
var b = new Point(1.0, 2.0);

Console.WriteLine(a == b); // True — value equality

record struct gives you:

Value type semantics (stack allocation, no GC pressure)
Value equality
with expression
No heap allocation

Use record struct for small, frequently used, immutable value objects.

When to Use Records

Use records for

DTOs (Data Transfer Objects) — data flowing between layers
API request/response models
Value objects in Domain-Driven Design
Query results that should not be mutated
Configuration objects
Any data where equality means "same values"

Do NOT use records for

Domain entities that have identity (an Order with an ID is not equal to another Order with the same values — they are separate things)
Services and repositories — these have behaviour, not just data
Objects with complex mutable state

Real-World Example

// ✅ Perfect use of record — API response DTO
public record OrderResponse(
    Guid Id,
    string CustomerName,
    decimal TotalAmount,
    DateTime CreatedAt
);

// ✅ With expression for building variations in tests
var baseOrder = new OrderResponse(Guid.NewGuid(), "Alice", 150.00m, DateTime.UtcNow);
var updatedOrder = baseOrder with { TotalAmount = 200.00m };

// ✅ Value equality in assertions
var expected = new OrderResponse(id, "Alice", 150.00m, createdAt);
var actual = service.GetOrder(id);

Assert.Equal(expected, actual); // Works because of value equality

Record Inheritance

Records support inheritance — but with one rule:

A record can only inherit from another record (not a class).

public record Animal(string Name);
public record Dog(string Name, string Breed) : Animal(Name);

var dog = new Dog("Rex", "Labrador");
Console.WriteLine(dog); // Dog { Name = Rex, Breed = Labrador }

Equality checks include all derived type properties.

Interview-Ready Summary

Records are reference types with value-based equality
Two records with the same values are considered equal
Properties are init-only by default — immutable after construction
Use with to create modified copies without mutating the original
record struct is a value type record — no heap allocation
Use records for DTOs, API models, value objects
Do not use records for domain entities that have identity

A strong interview answer:

"Records are designed for immutable data with value-based equality. Unlike classes where equality means same reference, two records with the same values are equal. The with expression lets you produce modified copies non-destructively. They're ideal for DTOs and value objects, but not for domain entities where identity matters more than content."

⭐ Add-On — Records in Pattern Matching

Records work exceptionally well with C# pattern matching.

public record Shape;
public record Circle(double Radius) : Shape;
public record Rectangle(double Width, double Height) : Shape;

double GetArea(Shape shape) => shape switch
{
    Circle(var r)          => Math.PI * r * r,
    Rectangle(var w, var h) => w * h,
    _                      => throw new ArgumentException("Unknown shape")
};

Positional patterns work directly with record deconstruction — no extra code needed.

Value Types vs Reference Types, Struct vs Class, and Boxing & Unboxing — The Complete C# Guide

Libin Tom Baby — Mon, 30 Mar 2026 05:07:40 +0000

Value/reference types, stack vs heap, struct vs class, boxing/unboxing performance traps

Value Types vs Reference Types, Struct vs Class, and Boxing & Unboxing

These three topics are deeply connected.

You cannot fully understand struct vs class without understanding the stack and heap.

You cannot fully understand boxing and unboxing without understanding value and reference types.

This guide covers all three together — the way they should be taught.

How .NET Manages Memory

Before anything else, you need to understand two memory regions.

The Stack

Fast allocation and deallocation
LIFO (Last In, First Out) structure
Stores value types and method call frames
Memory is automatically reclaimed when the method exits
Limited in size

The Heap

Slower allocation
Stores reference types (objects)
Managed by the Garbage Collector (GC)
Much larger than the stack
Memory is reclaimed by the GC, not deterministically

This distinction is the foundation of everything that follows.

Value Types

A value type holds its data directly in memory.

When you assign a value type to another variable, a copy is made.

int a = 10;
int b = a;
b = 20;

Console.WriteLine(a); // 10 — not affected
Console.WriteLine(b); // 20

Common value types

int, float, double, decimal
bool, char
DateTime, TimeSpan
struct
enum
Nullable value types (int?)

Where they live

Value types declared as local variables live on the stack.

Value types declared as fields inside a class live on the heap alongside the object.

Reference Types

A reference type stores a reference (pointer) to the actual data on the heap.

When you assign a reference type to another variable, both variables point to the same object.

var person1 = new Person { Name = "Alice" };
var person2 = person1;

person2.Name = "Bob";

Console.WriteLine(person1.Name); // Bob — both point to the same object

Common reference types

class
string
interface
delegate
Arrays
object

Where they live

The reference (the pointer) can live on the stack.

The actual object data always lives on the heap.

The Key Difference — Side by Side

	Value Type	Reference Type
Stores	Actual data	Reference to data
Assignment	Creates a copy	Shares the reference
Memory	Stack (usually)	Heap
Null	Not nullable by default	Nullable
GC involvement	None	Yes
Examples	`int`, `struct`	`class`, `string`

Struct vs Class

struct is a value type.

class is a reference type.

This single difference drives all the behaviour below.

Struct example

public struct Point
{
    public int X { get; set; }
    public int Y { get; set; }
}

var p1 = new Point { X = 1, Y = 2 };
var p2 = p1; // copy

p2.X = 99;

Console.WriteLine(p1.X); // 1 — unaffected
Console.WriteLine(p2.X); // 99

Class example

public class Point
{
    public int X { get; set; }
    public int Y { get; set; }
}

var p1 = new Point { X = 1, Y = 2 };
var p2 = p1; // same reference

p2.X = 99;

Console.WriteLine(p1.X); // 99 — both affected
Console.WriteLine(p2.X); // 99

Struct vs Class — Feature Comparison

Feature	Struct	Class
Type	Value type	Reference type
Memory	Stack (typically)	Heap
Inheritance	Cannot inherit	Supports inheritance
Default constructor	Implicit (zeroes fields)	Can define
Nullable	No (unless `Nullable<T>`)	Yes
Passed by	Value (copy)	Reference
GC pressure	None	Yes
Best for	Small, immutable data	Complex objects, behaviour

When to Use Struct

Use a struct when:

The data is small (typically under 16 bytes)
The type is logically a single value (a point, a colour, a coordinate)
Immutability is desired
You want to avoid heap allocation and GC pressure
The type will be used heavily in tight loops or collections

// Good struct candidates
public struct Coordinate { public double Lat; public double Lon; }
public struct Rgb { public byte R; public byte G; public byte B; }
public struct Money { public decimal Amount; public string Currency; }

When NOT to use struct

The data is large (copying becomes expensive)
The type needs inheritance
The type has mutable state that gets passed around
The type will be used as an interface (triggers boxing — explained below)

Boxing and Unboxing

Boxing and unboxing happen when a value type is treated as a reference type.

Boxing

Converting a value type to object (or an interface type).

int number = 42;
object boxed = number; // Boxing — a copy is placed on the heap

What happens under the hood:

Memory is allocated on the heap
The value is copied from the stack into the heap object
The object variable holds a reference to that heap memory

Unboxing

Converting a boxed object back to a value type.

object boxed = 42;
int unboxed = (int)boxed; // Unboxing — copies value back from heap to stack

What happens under the hood:

The runtime checks the type matches
The value is copied from the heap back to the stack

Why Boxing is Expensive

Boxing seems harmless. It isn't.

Every boxing operation:

Allocates heap memory
Triggers the Garbage Collector more frequently
Copies data (twice — once to box, once to unbox)
Adds CPU overhead from type checking

In hot paths — tight loops, high-frequency operations, large collections — boxing degrades performance significantly.

The Classic Boxing Trap — ArrayList

// ❌ Old way — ArrayList boxes every int
var list = new ArrayList();
for (int i = 0; i < 1_000_000; i++)
{
    list.Add(i); // Boxing happens 1,000,000 times
}

// ✅ New way — List<T> avoids boxing entirely
var list = new List<int>();
for (int i = 0; i < 1_000_000; i++)
{
    list.Add(i); // No boxing
}

List<T> uses generics — no boxing required.

ArrayList treats everything as object — boxing on every insert.

Another Common Trap — Interfaces and Structs

public interface IPrintable
{
    void Print();
}

public struct Message : IPrintable
{
    public string Text;
    public void Print() => Console.WriteLine(Text);
}

IPrintable msg = new Message { Text = "Hello" }; // ❌ Boxing!

Assigning a struct to an interface causes boxing.

The struct is copied to the heap so it can be referenced as an interface.

Spotting Boxing at Runtime

Boxing shows up as:

Increased GC collections (especially Gen0)
Memory pressure in profilers
System.Object allocations in heap snapshots

Use tools like:

dotMemory (JetBrains)
BenchmarkDotNet with memory diagnostics
Visual Studio Diagnostic Tools
GC.GetTotalMemory(false) for quick checks

Real-World Scenario

Scenario: Logging with string interpolation

int userId = 101;
bool isActive = true;

// ❌ Older pattern — potential boxing with format args
string.Format("User {0} active: {1}", userId, isActive);

// ✅ Modern — string interpolation compiles efficiently
$"User {userId} active: {isActive}";

// ✅ Best for hot paths — structured logging with no boxing via generics
_logger.LogInformation("User {UserId} active: {IsActive}", userId, isActive);

ILogger<T> uses generic overloads to avoid boxing on primitive arguments.

Interview-Ready Summary

Value types store data directly — assignment copies the value
Reference types store a pointer — assignment shares the reference
Stack = fast, limited, deterministic; Heap = larger, GC-managed
struct is a value type; class is a reference type
Use struct for small, immutable, short-lived data
Boxing converts a value type to object and allocates on the heap
Unboxing copies the value back from the heap
Boxing in loops or large collections silently destroys performance
Generics (List<T>) were introduced specifically to eliminate boxing
Assigning a struct to an interface triggers boxing

A strong interview answer:

"Value types hold their data directly and live on the stack by default, while reference types store a pointer to heap memory. Structs are value types best suited for small, immutable data. Boxing wraps a value type in a heap-allocated object — it's implicit, easy to miss, and expensive at scale. Generics eliminate boxing by preserving type information at compile time."

⭐ Add-On — Why This Matters More Now With record struct

C# 10 introduced record struct — a value type with built-in immutability and value equality.

public record struct Coordinate(double Lat, double Lon);

var a = new Coordinate(1.0, 2.0);
var b = new Coordinate(1.0, 2.0);

Console.WriteLine(a == b); // True — value equality, no boxing

This gives you the clean syntax of records without the heap allocation of reference-type records.

For high-performance scenarios where you want immutable data structures, record struct is now the go-to choice.

IDisposable, Finalizers, and the Dispose Pattern — The Complete Guide for .NET Developers

Libin Tom Baby — Mon, 02 Mar 2026 13:00:00 +0000

IDisposable, Finalizers, and the Dispose Pattern in .NET

Memory management in .NET is automatic thanks to the Garbage Collector (GC). But GC only handles managed memory. When your application interacts with unmanaged resources — file handles, database connections, sockets, streams, OS handles — the GC cannot clean them up.

That’s where IDisposable, finalizers, and the Dispose Pattern come in.

This guide explains how they work, why they exist, and how to implement them correctly in real-world .NET applications.

Why Do We Need IDisposable?

GC cleans up managed objects, but unmanaged resources live outside the .NET runtime.

Examples of unmanaged resources:

File handles
Network sockets
Database connections
OS handles
Native memory
GDI+ objects

These must be released deterministically, not “whenever GC runs.”

IDisposable gives you a way to clean up these resources immediately.

What Is IDisposable?

IDisposable defines a single method:

public interface IDisposable
{
    void Dispose();
}

Calling Dispose() releases unmanaged resources.

The `using` statement ensures cleanup

using (var stream = new FileStream("data.txt", FileMode.Open))
{
    // work with stream
} // Dispose() is called automatically here

This is deterministic cleanup — the resource is released immediately.

What Are Finalizers?

A finalizer (also called a destructor) is a method that runs when the GC collects an object.

~MyClass()
{
    // cleanup logic
}

But finalizers are expensive

They delay garbage collection
They require extra GC passes
They keep objects alive longer
They run on a background thread
Execution timing is unpredictable

Finalizers should be used only as a safety net, not as the primary cleanup mechanism.

The Dispose Pattern (The Correct Way)

When your class holds unmanaged resources, implement the full Dispose Pattern.

Standard implementation

public class ResourceHolder : IDisposable
{
    private bool _disposed = false;

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (_disposed) return;

        if (disposing)
        {
            // Dispose managed resources
        }

        // Free unmanaged resources

        _disposed = true;
    }

    ~ResourceHolder()
    {
        Dispose(false);
    }
}

Why this pattern?

Dispose(true) → clean managed + unmanaged resources
Dispose(false) → clean unmanaged only (finalizer path)
GC.SuppressFinalize → prevents finalizer from running unnecessarily

This ensures safe cleanup in all scenarios.

When Should You Implement IDisposable?

Implement IDisposable when your class:

Directly holds unmanaged resources
Wraps a type that implements IDisposable
Uses OS handles
Uses native memory
Uses streams, DB connections, HttpClient, etc.

Example: wrapping a disposable object

public class ReportWriter : IDisposable
{
    private readonly StreamWriter _writer;

    public ReportWriter(string path)
    {
        _writer = new StreamWriter(path);
    }

    public void Dispose()
    {
        _writer.Dispose();
    }
}

Common Mistakes

❌ Forgetting to call Dispose

Leads to file locks, memory leaks, socket exhaustion.

❌ Using finalizers unnecessarily

Hurts performance.

❌ Using `async void` with disposable resources

Exceptions become uncatchable.

❌ Disposing objects you don’t own

Only dispose what your class created.

SafeHandle — The Modern Way

Instead of writing finalizers manually, .NET recommends using SafeHandle.

public class MyResource : IDisposable
{
    private SafeHandle _handle = new SafeFileHandle(IntPtr.Zero, true);

    public void Dispose()
    {
        _handle.Dispose();
    }
}

Benefits

No need for finalizers
Built-in reliability
Better performance
Less boilerplate

Async Dispose (`IAsyncDisposable`)

For async cleanup:

public class MyAsyncResource : IAsyncDisposable
{
    public async ValueTask DisposeAsync()
    {
        await stream.DisposeAsync();
    }
}

Used for:

Asynchronous streams
Network operations
Database connections

Real‑World Scenarios

Scenario 1: File I/O

File handles must be released immediately.

Scenario 2: Database connections

Connection pools get exhausted if Dispose is not called.

Scenario 3: Network sockets

Unreleased sockets cause port exhaustion.

Scenario 4: Interop with native libraries

Unmanaged memory must be freed manually.

Interview‑Ready Summary

GC cleans managed memory, not unmanaged resources
IDisposable enables deterministic cleanup
Finalizers are a safety net, not the primary cleanup mechanism
The Dispose Pattern ensures safe cleanup in all cases
Use using or await using to guarantee disposal
Prefer SafeHandle over manual finalizers

A strong interview answer:

“IDisposable exists because GC cannot clean unmanaged resources. Dispose provides deterministic cleanup, while finalizers act as a fallback. The Dispose Pattern ensures both managed and unmanaged resources are released safely.”

Async/Await in C# — A Deep Dive Into How Asynchronous Programming Really Works

Libin Tom Baby — Sat, 28 Feb 2026 13:00:00 +0000

Async/Await in C#

Asynchronous programming is one of the most important concepts in modern .NET development. Whether you're building APIs, background services, or UI applications, understanding async and await is essential for writing scalable, responsive, and high‑performance code.

But many developers only know how to use async/await — not how it actually works under the hood. This guide breaks down the mechanics, the patterns, the pitfalls, and the real-world scenarios that matter in interviews and production systems.

Why Asynchronous Programming Exists

The goal of async programming is simple:

Free up threads instead of blocking them.

Blocking = waste

Async = efficiency

In a web server, every blocked thread reduces throughput.

In a UI app, blocking freezes the interface.

Async/await solves this by allowing operations to pause without blocking the thread.

What `async` Really Means

Marking a method as async:

Allows the use of await inside the method
Automatically wraps the return type in a Task or Task<T>
Does not make the method run on a background thread

Example

public async Task<int> GetNumberAsync()
{
    return 42;
}

This method is still synchronous unless it contains an awaited asynchronous operation.

What `await` Really Does

await does not create a new thread.

It:

Starts an asynchronous operation
Returns control to the caller
Resumes the method when the operation completes

Example

var data = await httpClient.GetStringAsync(url);

While waiting for the network response:

The thread is returned to the thread pool
No blocking occurs
The method resumes when the response arrives

Async/Await Under the Hood

When you write:

await SomeOperationAsync();

The compiler transforms your method into a state machine.

This state machine:

Tracks where execution paused
Resumes at the correct point
Handles exceptions
Handles return values

This is why async/await feels synchronous but behaves asynchronously.

Task vs Task vs void

Task

Represents an asynchronous operation with no return value.

Task

Represents an asynchronous operation that returns a value.

void

Only for:

Event handlers
Fire‑and‑forget operations (dangerous)

Never use async void in business logic — you lose exception handling.

Common Mistake: Blocking Async Code

var result = GetDataAsync().Result;   // ❌ Deadlock risk
var result = GetDataAsync().Wait();   // ❌ Deadlock risk

Blocking async code causes:

Deadlocks
Thread starvation
Performance issues

Always use await.

ConfigureAwait(false)

Used in library code to avoid capturing the synchronization context.

await SomeOperationAsync().ConfigureAwait(false);

When to use it

Class libraries
Background services
Anywhere except UI frameworks

When NOT to use it

ASP.NET Core (no sync context)
UI apps (WPF, WinForms) unless you know what you're doing

Parallelism vs Asynchrony

These two are often confused.

Asynchrony

Non‑blocking I/O

(Waiting without using a thread)

Parallelism

Multiple threads executing simultaneously

(CPU‑bound work)

Example: CPU‑bound

Parallel.For(0, 1000, i => DoWork());

Example: I/O‑bound

await httpClient.GetAsync(url);

Real‑World Scenarios

Scenario 1: Web API calling external services

public async Task<IActionResult> GetWeather()
{
    var data = await _weatherClient.GetAsync();
    return Ok(data);
}

Async frees the thread to handle other requests.

Scenario 2: Database calls

var user = await db.Users.FirstOrDefaultAsync(u => u.Id == id);

EF Core async methods prevent thread blocking.

Scenario 3: Background processing

await Task.Delay(5000);

Delays without blocking threads.

Scenario 4: File I/O

await File.WriteAllTextAsync("log.txt", message);

Async file operations scale better under load.

Interview‑Ready Summary

async enables await and returns a Task
await pauses without blocking
Async/await uses compiler‑generated state machines
Never block async code with .Result or .Wait()
Use async for I/O‑bound work
Use parallelism for CPU‑bound work
Avoid async void except for event handlers

A strong interview answer:

“Async/await allows non‑blocking I/O by returning threads to the pool while operations are in progress. The compiler generates a state machine that resumes execution when the awaited task completes. It improves scalability, especially in ASP.NET Core.”

SOLID Principles in C# — A Practical, Real‑World Guide for .NET Developers

Libin Tom Baby — Thu, 26 Feb 2026 13:00:00 +0000

SOLID Principles in C#

SOLID is one of those topics that shows up in every senior .NET interview — and for good reason. These five principles help you write cleaner, more maintainable, and more scalable code. But the real value comes from understanding how to apply them in real-world .NET systems.

This guide breaks down each principle with simple definitions, C# examples, and practical scenarios you can use in interviews or production code.

S — Single Responsibility Principle (SRP)

A class should have one and only one reason to change.

What it means

A class should do one thing.

Not “mostly one thing.”

Not “one thing plus a helper.”

Just one responsibility.

Bad example

public class OrderService
{
    public void CreateOrder(Order order) { }
    public void SendEmail(Order order) { }
}

This class handles business logic and emailing — two responsibilities.

Good example

public class OrderService
{
    public void CreateOrder(Order order) { }
}

public class EmailService
{
    public void SendEmail(Order order) { }
}

Real‑world scenario

Logging mixed with business logic
Controllers doing validation + mapping + business logic
Services doing too much

SRP makes your code testable and easier to maintain.

O — Open/Closed Principle (OCP)

Software entities should be open for extension but closed for modification.

What it means

You should be able to add new behavior without changing existing code.

Bad example

public class PaymentProcessor
{
    public void Pay(string method)
    {
        if (method == "CreditCard") { }
        else if (method == "PayPal") { }
        else if (method == "Crypto") { }
    }
}

Every new payment method requires modifying this class.

Good example

public interface IPaymentMethod
{
    void Pay();
}

public class CreditCard : IPaymentMethod { public void Pay() { } }
public class PayPal : IPaymentMethod { public void Pay() { } }

public class PaymentProcessor
{
    public void Pay(IPaymentMethod method) => method.Pay();
}

Real‑world scenario

Adding new features without breaking existing ones — especially in enterprise systems.

L — Liskov Substitution Principle (LSP)

Subclasses should be substitutable for their base classes.

What it means

If class B inherits from class A, you should be able to use B anywhere A is expected — without breaking behavior.

Bad example

public class Bird
{
    public virtual void Fly() { }
}

public class Penguin : Bird
{
    public override void Fly() => throw new Exception("Penguins can't fly");
}

This violates LSP — a Penguin is not a Bird in this model.

Good example

public abstract class Bird { }
public class FlyingBird : Bird { public void Fly() { } }
public class Penguin : Bird { }

Real‑world scenario

Inheritance hierarchies that break behavior or introduce exceptions.

I — Interface Segregation Principle (ISP)

Clients should not be forced to depend on interfaces they do not use.

What it means

Small, focused interfaces are better than large, bloated ones.

Bad example

public interface IWorker
{
    void Work();
    void Eat();
}

Robots don’t eat.

Good example

public interface IWorkable { void Work(); }
public interface IFeedable { void Eat(); }

Real‑world scenario

Large service interfaces with 20+ methods — most implementations only use a few.

D — Dependency Inversion Principle (DIP)

Depend on abstractions, not concrete implementations.

What it means

High-level modules should not depend on low-level modules.

Both should depend on interfaces.

Bad example

public class ReportService
{
    private readonly FileLogger _logger = new FileLogger();
}

Tightly coupled.

Good example

public class ReportService
{
    private readonly ILogger _logger;
    public ReportService(ILogger logger) => _logger = logger;
}

Now you can inject:

FileLogger
DatabaseLogger
CloudLogger

Real‑world scenario

Dependency Injection in ASP.NET Core is built entirely on DIP.

Putting SOLID Together — A Real .NET Example

Imagine building an order processing system:

SRP → OrderService handles orders only
OCP → Add new payment methods without modifying existing code
LSP → Subclasses behave correctly when substituted
ISP → Interfaces are small and focused
DIP → Services depend on abstractions, not concrete classes

This leads to cleaner architecture, easier testing, and safer refactoring.

Interview‑Ready Summary

SRP → One responsibility
OCP → Extend, don’t modify
LSP → Subtypes must behave correctly
ISP → Small interfaces
DIP → Depend on abstractions

A strong interview answer:

“SOLID helps create maintainable, scalable, and testable systems. It reduces coupling, improves extensibility, and keeps code clean as the system grows.”

⭐ Add‑On

Where Did SOLID Come From? A Brief Origin Story

SOLID didn’t appear out of nowhere — it has a clear lineage in software engineering history.

The principles were originally introduced by Robert C. Martin (Uncle Bob), one of the most influential figures in modern software craftsmanship. He coined the acronym SOLID in the early 2000s to group together five existing object‑oriented design principles that had been discussed in academic and professional circles for years.

The ideas themselves were heavily inspired by earlier work from:

Bertrand Meyer (creator of Eiffel) — especially the Open/Closed Principle
Barbara Liskov — whose Liskov Substitution Principle became the “L” in SOLID
Tom DeMarco, Grady Booch, and others — pioneers of structured and OO design

SOLID gained massive popularity because:

Uncle Bob promoted it through books, talks, and the Agile movement
It aligned perfectly with Test‑Driven Development (TDD)
It helped teams build maintainable, scalable systems
It became a cornerstone of Clean Architecture and modern .NET design

Today, SOLID is considered foundational knowledge for senior developers, architects, and anyone building long‑lived enterprise systems.

Dependency Injection Lifetime for DbContext in .NET: Choosing the Right Scope

Libin Tom Baby — Tue, 24 Feb 2026 13:00:00 +0000

Which DI Lifetime to Use for DbContext?

If you’ve worked with Entity Framework Core, you’ve probably seen the classic interview question:

“What lifetime should you use for DbContext — Scoped, Transient, or Singleton?”

The correct answer is Scoped, but understanding why is what separates a junior developer from a senior engineer.

This guide explains the reasoning, the internals, and real-world scenarios so you can answer confidently in interviews and write safer, more scalable applications.

What Is DbContext?

DbContext represents a unit of work and a session with the database.

It:

Tracks changes
Manages entity states
Handles database connections
Executes queries
Saves changes

Because it tracks state, its lifetime matters.

The Three DI Lifetimes in .NET

Before choosing the right one, here’s a quick refresher:

Transient

A new instance every time it’s requested.

Scoped

One instance per HTTP request.

Singleton

One instance for the entire application lifetime.

Why DbContext Should Be Scoped

✔️ 1. DbContext is not thread-safe

ASP.NET Core handles multiple requests concurrently.

If you use a Singleton DbContext, multiple threads will share the same instance.

This leads to:

Race conditions
Corrupted state
Random exceptions
Broken change tracking

✔️ 2. Scoped matches the unit-of-work pattern

Each HTTP request represents a business operation.

Examples:

Creating an order
Updating a profile
Processing a payment

A scoped DbContext ensures:

One context per operation
One transaction per request
Clean change tracking
Predictable behavior

✔️ 3. Scoped ensures proper connection management

DbContext opens and closes connections efficiently within the request scope.

Why NOT Transient?

Transient creates a new DbContext every time it’s injected.

This causes:

❌ Multiple DbContexts in the same request

You may accidentally:

Query with one context
Save with another
Lose change tracking
Break transactions

❌ Hard-to-debug inconsistencies

Different DbContexts don’t share state.

Why NOT Singleton?

Singleton is the worst possible choice.

❌ DbContext is not thread-safe

Multiple requests → shared instance → chaos.

❌ Memory leaks

The context keeps tracking more and more entities.

❌ Stale data

Long-lived DbContexts cache query results.

❌ Broken transactions

A single DbContext cannot manage multiple concurrent operations.

Real‑World Scenarios

Scenario 1: Web API request

User updates their profile.

One request
One DbContext
One transaction

Use Scoped

Scenario 2: Background service

A hosted service processes messages from a queue.

Each message should have its own DbContext.

using var scope = _serviceProvider.CreateScope();
var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();

Use Scoped inside a created scope

Scenario 3: Console app

Short-lived operations.

Transient or Scoped both work, but Scoped is still preferred for consistency.

How to Register DbContext Correctly

services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(Configuration.GetConnectionString("Default")));

This registers DbContext as Scoped by default.

Interview‑Ready Summary

DbContext should be Scoped
DbContext is not thread-safe
Scoped aligns with unit-of-work
Singleton causes race conditions and memory leaks
Transient causes multiple contexts per request

A clean, senior-level answer:

“DbContext should be registered as Scoped because it represents a unit of work per request, is not thread-safe, and must not be shared across concurrent operations. Transient creates too many contexts, and Singleton causes concurrency issues and stale tracking.”

Understanding Garbage Collection (GC) in .NET — How It Works and When It Matters

Libin Tom Baby — Sun, 22 Feb 2026 13:00:00 +0000

Garbage Collection (GC) in .NET

Memory management is one of the most important concepts in .NET. Developers often say “the Garbage Collector handles memory for you,” but few can clearly explain how it works, why it exists, and what you can do to work with it instead of against it.

This guide breaks down .NET’s Garbage Collection (GC) in a simple, practical way — with definitions, diagrams, examples, and real-world scenarios.

What Is Garbage Collection?

Garbage Collection (GC) is an automatic memory management system in .NET.

Its job is to:

Allocate memory for new objects
Track which objects are still in use
Free memory for objects that are no longer needed
Prevent memory leaks
Reduce developer errors like dangling pointers

In short: GC keeps your application healthy by cleaning up unused objects automatically.

How GC Works in .NET

The .NET GC uses a generational, mark‑and‑compact algorithm.

Let’s break that down.

1. Generations (Gen 0, Gen 1, Gen 2)

Objects are grouped into generations based on their lifetime.

Generation 0

Newly created objects
Collected frequently
Fastest to clean

Generation 1

Surviving objects from Gen 0
Medium‑lived objects

Generation 2

Long‑lived objects
Large objects
Cleaned infrequently

Why generations?

Most objects die young.

So GC optimizes for that.

2. Mark Phase

GC pauses the application briefly and marks all objects that are still reachable.

Reachable means:

Local variables
Static references
Objects referenced by other objects

Everything else is considered garbage.

3. Compact Phase

After marking, GC compacts memory by moving surviving objects together.

This reduces fragmentation and improves performance.

4. Large Object Heap (LOH)

Objects > 85 KB go to the Large Object Heap.

Not compacted often (expensive to move large objects)
Can cause fragmentation
Avoid unnecessary large allocations

When Does GC Run?

GC runs automatically when:

Memory is low
Gen 0 fills up
The system is under pressure
You explicitly call GC.Collect() (not recommended)

Should You Call `GC.Collect()`?

Almost never.

Calling it manually:

Forces a full collection
Pauses your app
Hurts performance
Breaks GC’s optimization logic

Use it only in rare scenarios:

After a massive one‑time memory release
In controlled environments (e.g., game engines)

How to Work With GC (Best Practices)

✔️ Use `using` statements for disposable objects

using (var stream = new FileStream("data.txt", FileMode.Open))
{
    // work with stream
}

This ensures deterministic cleanup.

✔️ Avoid unnecessary large object allocations

var bigArray = new byte[100_000]; // Goes to LOH

Reuse buffers when possible.

✔️ Prefer `Span<T>` and `Memory<T>` for high-performance scenarios

These avoid heap allocations.

✔️ Avoid long-lived references

If you keep references alive, GC cannot collect them.

✔️ Use dependency injection wisely

Singletons live for the entire app lifetime — avoid storing large objects inside them.

Real‑World Scenarios

Scenario 1: Web API handling thousands of requests

Short-lived objects → Gen 0

GC handles them efficiently.

Scenario 2: Image processing

Large byte arrays → LOH

Avoid repeated allocations; use pooling.

Scenario 3: Background services

Long-lived services → Gen 2

Be careful with memory leaks.

Interview‑Ready Summary

GC automatically manages memory in .NET
Uses generational collection (Gen 0, 1, 2)
Uses mark and compact algorithm
LOH stores large objects
Avoid calling GC.Collect() manually
Use using, pooling, and DI best practices

This explanation shows you understand both the theory and the practical implications.

✅ Bonus thought

Is `IDisposable` Related to Garbage Collection? Clearing the Confusion

Many developers — especially those new to .NET — assume that IDisposable is part of the Garbage Collector. It’s a common misunderstanding, but the two concepts solve different problems.

Garbage Collection handles managed memory

GC automatically frees memory for objects stored on the managed heap.

Examples:

Classes
Strings
Arrays
Delegates

GC decides when to clean them up.

IDisposable handles unmanaged resources

IDisposable exists because GC cannot clean up unmanaged resources, such as:

File handles
Database connections
Network sockets
OS handles
Streams
Native memory

These require deterministic cleanup, which is why we use:

using (var stream = new FileStream("data.txt", FileMode.Open))
{
    // work with stream
}

How they relate

GC cleans up managed memory
IDisposable cleans up unmanaged resources
Finalizers (~ClassName) act as a safety net, but they are expensive
The using statement ensures cleanup happens immediately, not “whenever GC runs”

The rule of thumb

GC ≠ Dispose

GC frees memory

Dispose frees resources

This distinction is crucial in interviews and real-world systems.

What the 'sealed' Keyword Means in C# — And When You Should Use It

Libin Tom Baby — Fri, 20 Feb 2026 13:00:00 +0000

`sealed` Keyword in C#

The sealed keyword is one of those C# features that developers see often but rarely think deeply about. It quietly influences inheritance, performance, and API design — especially in large systems and frameworks.

This guide explains what sealed does, why it exists, and when you should (and shouldn’t) use it, with practical examples and real-world scenarios.

What Does `sealed` Mean?

The sealed keyword prevents a class from being inherited or prevents a virtual method from being overridden further.

You can apply sealed to:

A class
A method (when overriding a virtual method)

1. Sealed Classes

A sealed class cannot be inherited.

Example

public sealed class Logger
{
    public void Log(string message)
    {
        Console.WriteLine(message);
    }
}

Trying to inherit from it:

public class CustomLogger : Logger {} 
// ❌ Error: cannot derive from sealed type

Why seal a class?

To prevent misuse through inheritance
To lock down behavior
To improve performance (JIT optimizes sealed classes)
To protect API design in libraries

2. Sealed Methods

You can also seal a method, but only when overriding a virtual method.

Example

public class Base
{
    public virtual void Process() {}
}

public class Child : Base
{
    public sealed override void Process()
    {
        // Implementation
    }
}

public class GrandChild : Child
{
    public override void Process() {} 
    // ❌ Error: cannot override sealed method
}

Why seal a method?

To stop further overrides
To preserve behavior
To avoid breaking logic in subclasses

Why Does `sealed` Improve Performance?

When a class is sealed:

The JIT compiler knows no subclass will override methods
It can devirtualize calls
It can inline methods
It can optimize dispatch

This makes sealed classes slightly faster, especially in tight loops or high-frequency calls.

This is why many .NET framework classes (e.g., String) are sealed.

Real‑World Scenarios

Scenario 1: Utility classes

Utility classes like Math, String, or Path are sealed because:

They are not meant to be extended
Inheritance would cause confusion
Behavior must remain consistent

Scenario 2: Preventing fragile inheritance

If you expose a class in a public API, consumers might inherit from it in unexpected ways.

Sealing the class protects your design.

Scenario 3: Performance‑critical components

High-performance libraries often seal classes to allow JIT optimizations.

Scenario 4: Sealing methods in a hierarchy

You may want to allow inheritance but restrict certain behaviors.

public class Animal
{
    public virtual void Move() {}
}

public class Bird : Animal
{
    public sealed override void Move()
    {
        // Birds fly
    }
}

Now no subclass of Bird can change how Move() works.

When NOT to Use `sealed`

When you expect developers to extend your class
When you’re building a framework that encourages inheritance
When sealing would limit testability (mocking frameworks often rely on inheritance)

Interview‑Ready Summary

sealed prevents inheritance
Sealed classes = no subclassing
Sealed methods = no further overrides
Sealing improves performance via JIT optimizations
Use it to protect API design, prevent misuse, and optimize performance

Forem: Libin Tom Baby

How Dependency Injection Works Internally in .NET

The Three Building Blocks

1. IServiceCollection — the registration

2. IServiceProvider — the container

3. Resolution — how objects are constructed

The Three Lifetimes — Explained Internally

Singleton

Scoped

Transient

How Constructor Injection Works

The Captive Dependency Problem

Resolving Services Manually

Interview-Ready Summary

The Middleware Pipeline in ASP.NET Core — How It Really Works

What Is Middleware?

The Three Methods: Use, Run, Map

Use — calls the next component

Run — terminal, does NOT call next

Map — branches based on path

Ordering Matters — A Lot

Short-Circuiting the Pipeline

Building Custom Middleware

Inline (simple cases)

Class-based (preferred for complex middleware)

Real-World Scenarios

Logging every request and response

Adding a correlation ID to every response

Interview-Ready Summary

Threading vs Tasks vs Parallelism — The Complete .NET Concurrency Guide

The Mental Model

Thread — The Low-Level Primitive

What you get

What it costs

When to use Thread directly

ThreadPool — Reusing Threads

Why this matters

When to use ThreadPool directly

Task — The Modern Standard

Task represents a promise

Combining Tasks

async/await — Asynchrony Without Blocking

The critical distinction

Parallel — True CPU Parallelism

Parallel.For

Parallel.ForEach

PLINQ

When to use Parallel

The Decision Framework

Common Mistakes

Mistake 1: Using Task.Run for I/O-bound work

Mistake 2: Using async/await for CPU-bound work

Mistake 3: Parallel for I/O

Interview-Ready Summary

IAsyncEnumerable Explained — Async Streams in .NET

The Problem They Solve

Option 1: Return everything at once

Option 2: Synchronous yield

Option 3: IAsyncEnumerable — the right way

How It Works

How to Produce an Async Stream

How to Consume an Async Stream

Cancellation Support

Producer with cancellation

Consumer with cancellation

IAsyncEnumerable vs IEnumerable

IAsyncEnumerable vs Task<List<T>>

Real-World Scenarios

Scenario 1: Streaming database records

Scenario 2: Streaming an external API

Scenario 3: Reading a large file line by line

Scenario 4: Exposing async streams from an API endpoint (ASP.NET Core)

Interview-Ready Summary

Record Types in C# — Immutability, Equality, and When to Use Them

Record Types in C#

What is a Record?

Value Equality — The Core Difference

Class (reference equality)

Record (value equality)

Immutability With init

1. `IServiceCollection` — the registration

2. `IServiceProvider` — the container

`Use` — calls the next component

`Run` — terminal, does NOT call next

`Map` — branches based on path

Immutability With `init`

The `with` Expression

The `using` statement ensures cleanup

❌ Using `async void` with disposable resources

Async Dispose (`IAsyncDisposable`)

What `async` Really Means