Interview Prep

The CLR uses a generational GC (Gen0, Gen1, Gen2). Short-lived objects start in Gen0 and are collected frequently with low cost. Objects that survive promotions land in Gen2, which is collected rarely. The GC uses a mark-and-sweep + compaction algorithm — it marks all live roots, sweeps unreachable objects, and compacts heap memory.

To minimise leaks: implement IDisposable and use using blocks for unmanaged resources. Unsubscribe from static events (a classic leak — the event source keeps the subscriber alive). Use WeakReference for caches so cached objects can be collected. Be careful with closures capturing large objects. Use memory profilers like dotMemory or the VS Diagnostic Tools to detect unexpected Gen2 promotions or growing retained bytes.

The compiler transforms an async method into a state machine. When you hit await, the current thread is released back to the thread pool while the awaited operation completes. A SynchronizationContext captures the ambient context (e.g., UI thread in WPF/WinForms) and marshals continuations back to that specific thread.

To prevent starvation: use ConfigureAwait(false) in library code so continuations don't marshal back unnecessarily. Never call .Result or .Wait() on a Task — this blocks a thread pool thread, which can deadlock when combined with a sync context. Avoid creating excessive parallel tasks without throttling via SemaphoreSlim. Monitor with ThreadPool.GetAvailableThreads() in diagnostics.

IEnumerable executes in-memory — EF fetches all rows from the DB first, then C# filters the results. IQueryable builds an expression tree that EF translates into SQL, executing the filter at the database level.

Use IQueryable when building EF query chains that should result in a single optimised SQL query. Switch to IEnumerable once you've called .ToList() and are working in memory. A common mistake is calling .AsEnumerable() mid-query accidentally, pulling back a million rows and filtering in C#. Always call .ToList() as late as possible and as close to the service/controller boundary as you can.

DI decouples concrete implementations from consumers, enabling testability, loose coupling, and easy swap of implementations. .NET's built-in IServiceCollection supports three lifetimes: Scoped (one instance per HTTP request), Transient (new instance each time), and Singleton (one instance for the app's lifetime).

For large systems like an MDM platform, DI is critical — it lets you inject mocked versions of device management clients, push notification providers, and database contexts during unit testing without touching real infrastructure. It also enforces the Single Responsibility Principle; if a constructor has 8 parameters, that's a code smell telling you a class is doing too much.

Task.Run is the modern, safe wrapper — it always queues to the default thread pool scheduler and correctly unwraps nested Tasks. Task.Factory.StartNew is lower-level and dangerous: it inherits the current scheduler, doesn't automatically unwrap async lambdas (you need .Unwrap()), and can schedule on the UI thread unexpectedly.

To prevent starvation: avoid blocking calls (no .Wait()/.Result). Use SemaphoreSlim to throttle the number of concurrent operations. Keep async all the way up the call stack. For long-running CPU work, pass TaskCreationOptions.LongRunning to StartNew so it spins up a dedicated thread rather than consuming a pool slot.

• class — Reference type on the heap. Use for entities with identity, mutable state, and behaviour. The default choice for most domain objects.
• struct — Value type on the stack. Use for small, immutable data where copy semantics are correct and allocation overhead matters (e.g., Point, Colour, Decimal wrappers). Avoid large structs — copying is expensive.
• record — Immutable reference type with value-based equality baked in. Perfect for DTOs, API response models, and domain value objects (e.g., Money, Address). record struct gives you value semantics plus concise syntax.

Rule of thumb: entities get classes, value objects get records, and performance-critical tiny data gets structs.

Use URL versioning (/api/v1, /api/v2) or header-based versioning via the Asp.Versioning NuGet package. The golden rule: never remove or rename fields on an existing contract — only add new optional fields. Treat your request/response models as append-only.

Run both route handlers side-by-side. Deprecate v1 with a Sunset response header giving clients a migration deadline. Use feature flags for a gradual rollout of new behaviour. Document every breaking change prominently. The goal is that v1 clients keep working untouched while v2 clients get the new capabilities.

LINQ introduces delegate allocations on every call, boxing for value types, and deferred evaluation that can be misused. Avoid multiple enumerations of the same query (call .ToList() once and reuse). In hot paths, a raw for loop with early exit will outperform LINQ significantly. Watch out for N+1 queries in EF when using LINQ without .Include().

For extremely high-throughput scenarios, consider Span<T>, ArrayPool<T>, or raw ADO.NET with Dapper for reads. Reserve LINQ for readability where performance is not critical, and profile with BenchmarkDotNet before optimising prematurely.

Records are reference types that compile with value-based equality baked in — Equals(), ==, and GetHashCode() are auto-generated based on all properties, not object reference. Positional records (record Person(string Name, int Age)) auto-generate a primary constructor, Deconstruct(), and immutable init-only setters.

The with expression performs non-destructive mutation — it creates a shallow copy with the specified properties changed: var updated = original with { Age = 31 };. The original is untouched. Under the hood, with calls a compiler-generated Clone() method then sets the changed properties. Key for domain value objects that should be immutable but need to produce modified versions.

• record struct — Value type with compiler-generated value equality and with support. Mutable by default (unlike record class). Good for lightweight value objects like Coordinate or DateRange.
• readonly struct — Guarantees all fields are readonly; the struct can never be mutated after creation. Enables compiler optimisations — in parameters pass by reference without defensive copies. Ideal for high-performance structs in hot paths.
• ref struct — Must live exclusively on the stack; cannot be boxed, stored in arrays, assigned to object, or captured in lambdas. Enables safe zero-allocation access to stack memory. Span<T> and ReadOnlySpan<T> are the canonical examples — critical for high-performance parsing and buffer manipulation.

Reflection uses the System.Reflection API to inspect types, invoke methods, and read/write properties at runtime. It bypasses compile-time type safety and is typically 10–100× slower than direct calls due to metadata lookups, lack of JIT inlining, and boxing of value type arguments.

Mitigations: cache MethodInfo and PropertyInfo instances rather than calling GetMethod() on every invocation. Use compiled expression trees (Expression.Lambda<Func<T>>) to generate a delegate once and call it at near-direct speed. The modern preferred alternative is Source Generators (Roslyn) — they run at compile time, produce strongly-typed code, and have zero runtime overhead. The System.Text.Json source generator is a textbook example.

An Expression<TDelegate> represents a lambda as a data structure (an AST) rather than compiled IL. This lets you inspect and transform code at runtime. Entity Framework translates LINQ expressions into SQL using this mechanism — it walks the expression tree and builds a parameterised query.

Practical uses: building dynamic filter predicates for EF queries at runtime (safer than string concatenation), generating fast-path property accessors (compile once, call thousands of times at near-native speed), and implementing specification patterns where predicates are composable. The key mental model: Func<T, bool> is executable code; Expression<Func<T, bool>> is inspectable data that can also be compiled.

Source Generators are Roslyn extensions that run during compilation and emit additional C# code into the compilation. The generated code is fully strongly-typed, AOT-compatible, and has zero runtime overhead. They're ideal for eliminating boilerplate that would otherwise require reflection: serialisers, DI registration, mapping code, validators.

Key examples: System.Text.Json source gen for allocation-free JSON serialisation, Refit for generating HTTP client interfaces. Use them when you find yourself writing the same reflection pattern across the codebase. The incremental generator API (IIncrementalGenerator) ensures only changed syntax nodes are reprocessed, keeping build times acceptable.

• Span<T> — A stack-only ref struct providing a view over contiguous memory (array slice, stack buffer, or native memory). Zero allocation for slicing. Use for synchronous high-performance parsing in hot paths.
• Memory<T> — The heap-compatible counterpart to Span. Can be stored in fields and used across await boundaries. Slightly more overhead but still allocation-free for slicing.
• ArrayPool<T> — Rent a buffer, use it, return it. Avoids GC pressure from frequent large array allocations. Critical in serialisation and network I/O. Always return arrays in a finally block.

unsafe enables pointer arithmetic, direct memory access, and fixed statements (pinning a managed object so the GC can't move it). Legitimate uses: P/Invoke interop with native libraries, writing high-performance parsers that manipulate raw bytes, and hardware-level operations.

Risks: no bounds checking (buffer overruns cause corruption or security vulnerabilities), pinned objects fragment the managed heap, and unsafe code can corrupt the process in ways that are very hard to debug. Modern preference: use Span<T> and MemoryMarshal to get most of the performance without unsafe semantics. Reserve true unsafe blocks for P/Invoke scenarios where no managed alternative exists.

• ConcurrentDictionary — Fine-grained striped locking allows multiple simultaneous readers and writers. Use for shared mutable state from many threads. Watch out: GetOrAdd's factory can be called multiple times concurrently; use AddOrUpdate when the value must be computed exactly once.
• ImmutableDictionary — All mutations return a new instance. Safe for concurrent reads with no locking. Best for config/lookup tables that are infrequently rebuilt. Slower writes.
• Dictionary + lock — Coarse-grained, simple to reason about. The right choice when a batch of operations must be atomic as a unit. For low-contention, the overhead is negligible.

• lock(obj) — Syntactic sugar for Monitor.Enter/Exit. In-process only. Fast, but can't be used across await points.
• Monitor — Gives you TryEnter with a timeout and Wait/Pulse for producer-consumer signalling. Still in-process.
• Mutex — OS-level, works across processes. Use for single-instance apps or cross-process resource guards. Much slower than Monitor.
• SemaphoreSlim — The async-compatible primitive. await semaphore.WaitAsync() releases the thread while waiting (unlike lock which blocks). Use to throttle concurrent async operations. The go-to tool for async concurrency control.

volatile prevents compiler and CPU reordering and ensures every read goes to main memory rather than a CPU cache. Use for simple flags read by one thread and written by another. Does not give you atomicity for compound operations.

Interlocked provides atomic CPU-level operations: Interlocked.Increment, CompareExchange, Add. No lock needed, no torn reads. Perfect for shared counters. lock is needed when you have compound read-modify-write logic that must be atomic as a unit. Rule of thumb: Interlocked for counters, SemaphoreSlim for async guards, lock for multi-step critical sections.

Channel<T> is a modern async-native producer-consumer queue. Producers await writer.WriteAsync(item) and consumers await reader.ReadAsync() — no polling, no busy waiting, full async throughout.

ConcurrentQueue is synchronous — TryDequeue returns false when empty, forcing you to poll or signal manually. Channel is the superior abstraction. With BoundedChannel, you get built-in backpressure — producers are suspended when the buffer is full rather than growing unboundedly. Use it for worker pipelines, log ingestion, and any scenario where producers and consumers run at different speeds.

IAsyncEnumerable<T> lets you produce values lazily across await points using yield return in an async method. The consumer iterates with await foreach. Instead of fetching all 50,000 records into a List before returning, you stream each item as soon as it's ready.

Real-world use: streaming database results with Dapper's QueryUnbufferedAsync, paginating through a third-party API, or streaming server-sent events to a client. Memory stays constant regardless of total result size. EF Core supports it directly via AsAsyncEnumerable(). Supports CancellationToken via the [EnumeratorCancellation] parameter.

Task is a heap-allocated reference type. Even when an async method completes synchronously (common for cache hits), it still allocates a Task object. ValueTask is a struct that avoids that allocation when the operation completes synchronously — it only allocates if it actually needs to await.

Use ValueTask when: the method frequently completes synchronously and the method is on a hot path at very high frequency. Critical pitfall: never await a ValueTask more than once and never store it for later — it can only be consumed once. For anything not on a hot path, use Task for simplicity.

Cancellation is cooperative — you call CancellationTokenSource.Cancel() and the operation checks token.IsCancellationRequested or calls token.ThrowIfCancellationRequested(). Always pass the token down to every async call so the entire chain cancels cleanly.

CancellationTokenSource.CreateLinkedTokenSource(token1, token2) creates a composite token that fires if either source fires. Classic use: combine a request-scoped token (from ASP.NET's HttpContext.RequestAborted) with a timeout token so an operation cancels on whichever comes first. Always dispose CancellationTokenSource — it registers a timer internally for timeouts and leaks if not disposed.

• Parallel.ForEach — CPU-bound work over a collection. Uses the thread pool with configurable MaxDegreeOfParallelism. Blocks until all iterations complete. Good for image resizing, batch data transformation.
• PLINQ (.AsParallel()) — Parallel LINQ for collection processing. Less control over thread count. Best for CPU-bound, stateless transformations.
• Task.WhenAll — For I/O-bound async work — firing multiple HTTP calls or DB queries concurrently. No new threads created; the pool resumes continuations as each completes. Using Parallel.ForEach for async I/O is a classic mistake — it blocks threads rather than releasing them.

Classic deadlock: in legacy ASP.NET a sync context allows only one thread at a time. You call .Result or .Wait() on an async Task. This blocks the sync context thread. When the Task completes, it tries to marshal its continuation back to that same thread — which is blocked. Both sides wait for each other — deadlock.

Fix 1: never block on async code — go async all the way up the stack. Fix 2: in library code, add ConfigureAwait(false) on every await so continuations don't need to return to the original context. Fix 3: use Task.Run() to execute on a thread pool thread with no sync context. ASP.NET Core removed this problem, but it still exists in WPF, WinForms, and legacy ASP.NET.

• where T : class — Reference type only. Enables nullability checks and reference equality.
• where T : struct — Value type only. Useful for numeric algorithms or stack-allocation guarantees.
• where T : new() — Must have a parameterless constructor. Lets you call new T() inside the generic method — useful for factory patterns.
• where T : ISomeInterface — Enables calling interface methods without reflection.
• where T : unmanaged — No managed references. Enables Span<T>, sizeof(T), and pointer operations. Critical for high-performance serialisation.
• where T : notnull — Cannot be nullable. Improves null-safety in generic utility methods.

Covariance (out): allows IEnumerable<Derived> to be used where IEnumerable<Base> is expected — safe because you're only reading items, never writing. IEnumerable<T> declares T as covariant.

Contravariance (in): IComparer<Base> can be used where IComparer<Derived> is expected — if you can compare any Base, you can compare a Derived. Action<T> is contravariant. Only interfaces and delegates support variance — classes do not. Common bug: developers assume List<Derived> is a List<Base> — it isn't, because List allows writes which would corrupt type safety.

• Type pattern: if (obj is Order o) — tests type and binds in one step.
• Switch expression: returns a value directly with no fall-through: status switch { OrderStatus.Paid => "Paid", _ => "Unknown" }
• Property pattern: order is { Status: OrderStatus.Paid, Total: > 100 } — match on property values inline.
• Positional pattern: deconstructs a record/tuple: (var x, var y) is (> 0, > 0)
• List pattern (C# 11): [first, .., last] matches arrays/lists by structure.
• Guard clause (when): additional condition after type match.

These replace long if-else chains and are especially powerful for discriminated union-style modelling with sealed record hierarchies.

Enabling <Nullable>enable</Nullable> makes the compiler track nullability. string is now non-nullable by default — a string? must be checked before use. Compiler warnings replace what were formerly silent NullReferenceException crashes at runtime.

Gotchas: the compiler uses flow analysis but can't know everything — you sometimes need the null-forgiving operator (!) to suppress a false positive (use sparingly). NRT is opt-in per file/project. Retrofitting an existing codebase requires patience — enable per assembly and fix warnings in batches. Never use ! as a shortcut without understanding the actual nullability.

init accessors allow a property to be set in an object initialiser but become read-only after construction — providing immutability without forcing a constructor with many parameters.

required forces callers to set a property in the object initialiser — the compiler raises an error if it's omitted. Together: class OrderDto { public required string OrderId { get; init; } } — callers must provide OrderId and can't change it afterwards. This is the modern alternative to large constructor parameter lists for DTOs and configuration objects. Much safer than having optional setters that callers might forget.

Primary constructors declare constructor parameters directly on the class: class OrderService(IOrderRepository repo, ILogger<OrderService> logger). The parameters are in scope throughout the class body — no need to assign them to private fields manually.

Pitfalls: primary constructor parameters are not automatically stored as fields — the compiler captures them only where needed. If the parameter is a mutable reference type accessed in multiple methods, you have one shared capture. For DI services this is fine. For value types or mutable objects you intend to copy independently, the capture semantics can be surprising. Debugging tools may show them differently to normal fields.

Extension methods are static methods in a static class where the first parameter has the this modifier. They appear as instance methods at the call site — the compiler rewrites myString.TruncateTo(50) as a static call. They cannot access private members, cannot be overridden, and don't participate in virtual dispatch.

Design limitations: they can conflict with actual instance methods (instance always wins), and they can create confusing intellisense when overused. Best uses: fluent builder chains, adding utility methods to types you don't own, and the entire LINQ operator pipeline. Avoid using them to work around poor class design — if a type genuinely needs that method, it should usually be on the type itself.

Implicit conversions happen automatically with no cast syntax. Use only when the conversion is always safe and lossless. If there's any possibility of data loss or failure, implicit conversion is dangerous because it happens silently.

Explicit conversions require a cast and should be used when the conversion can fail, lose precision, or requires the developer to opt in deliberately. For strongly-typed ID types (like OrderId wrapping a Guid), a clean pattern is: implicit from the primitive to the ID type (constructing is always safe), explicit back to the primitive (unwrapping should be deliberate). Never implement implicit conversions between unrelated domain types.

Implement IEquatable<T> (typed Equals), override object.Equals(object), override GetHashCode(), and overload == and !=. Critical rule: if two objects are equal, their hash codes must be identical. Violating this breaks Dictionary and HashSet lookups silently.

Use HashCode.Combine(field1, field2) to combine all fields that participate in equality. For records, all this is generated automatically. For mutable types: never base GetHashCode on mutable state — the hash would change after mutation, orphaning the object in any hash-based collection it's stored in.

Lazy<T> is the correct tool. new Lazy<T>(() => new ExpensiveService(), LazyThreadSafetyMode.ExecutionAndPublication) ensures the factory runs exactly once even under concurrent access. Accessed via .Value. The thread safety mode blocks all threads until the first one completes initialisation.

Manual double-checked locking is the low-level alternative — only correct when combined with a volatile field to prevent CPU reordering. In practice, Lazy<T> should be your default. For async lazy initialisation, Lazy<Task<T>> works but the factory might run multiple times without ExecutionAndPublication.

The full pattern: implement a public Dispose() that calls Dispose(true) and GC.SuppressFinalize(this). Add a protected virtual Dispose(bool disposing) method — when disposing is true, release both managed and unmanaged resources; when false (called from the finalizer), release only unmanaged resources.

You only need a finalizer (~ClassName) when your class directly holds unmanaged resources (raw OS handles, native pointers). For most code wrapping managed disposables (streams, DB connections), a simple IDisposable without a finalizer is correct. Finalizers increase GC pressure — objects with them are promoted to Gen1 before cleanup. SafeHandle is the modern alternative to manual finalizers for OS handles.

IAsyncDisposable defines ValueTask DisposeAsync() and is used with await using. Use it when cleanup involves async operations — flushing a buffer to a stream, closing a database connection gracefully, or waiting for a background task to drain before shutdown.

If you call a synchronous Dispose() on a resource needing to flush async data, you either block (bad) or lose data. StreamWriter and DbConnection implement both interfaces. For your own types: if cleanup is sync only, use IDisposable. If cleanup has I/O or awaitable work, implement IAsyncDisposable. Prefer implementing both when your type will be used in both sync and async contexts.

Since C# 7.2, you can assign stackalloc directly to a Span<T> without an unsafe context: Span<byte> buffer = stackalloc byte[128];. The memory lives on the stack frame and is freed automatically when the method returns — zero GC involvement.

Critical: never let the Span escape the method (returning it, storing in a field, or passing across an await boundary will reference freed stack memory). For buffers larger than a few kilobytes, prefer ArrayPool<byte>.Shared.Rent() — stack overflow is a real risk with large stackalloc. The pattern of stackalloc for small buffers and ArrayPool for larger ones is standard in high-performance .NET code like ASP.NET Kestrel.

A delegate instance holds an invocation list — multiple methods combined with +=. When invoked, all are called in order. For return values, only the last delegate's return value is kept.

Risks: if any subscriber throws an exception, subsequent subscribers in the list are skipped. Fix: iterate GetInvocationList() manually with a try/catch per delegate. The classic memory leak: a long-lived publisher holds a reference to a short-lived subscriber through the delegate — the subscriber can never be GC'd until it unsubscribes (-=). Solutions: WeakEvent pattern, or use IObservable/Rx with explicit subscription disposal via the returned IDisposable.

Default interface implementations (C# 8): interfaces can provide method bodies. Primary motivation: adding a new method to a published interface without breaking all existing implementations. Downside: it muddies the interface/abstract class distinction and the default method isn't accessible through a concrete type variable — only through the interface reference.

Static abstract interface members (C# 11): interfaces can declare static members that implementations must provide. The killer use case is generic math — INumber<T> declares static abstract T operator +(T left, T right), enabling truly generic arithmetic algorithms like T Sum<T>(IEnumerable<T> values) where T : INumber<T>. Previously impossible without boxing or dynamic dispatch.

Virtual method calls go through the vtable — an indirection that prevents the JIT from inlining the call or devirtualising it. When a class or method is sealed, the JIT knows the exact target at compile time and can inline, eliminating the vtable lookup overhead. In benchmarks on hot paths this can be a meaningful speedup.

When to seal: seal classes that are not designed for inheritance — it's an explicit design signal and a JIT hint. For override methods on non-sealed classes, sealed override prevents further subclasses from overriding while allowing devirtualisation on that specific type. The .NET runtime seals many core types for this reason. Don't seal everything prematurely — seal where it's architecturally intentional.

Microsoft.Extensions.ObjectPool provides a thread-safe pool where you Get() an instance, use it, then Return() it. Beyond capacity, extra returned objects are discarded for GC. StringBuilder pooling is the textbook example — string concatenation in loops is a common GC hotspot.

Use it for objects that are: expensive to create, used frequently for short durations, and can be reset to a clean state before reuse. The requirement that returned objects must be safely resetable is the main constraint — if cleanup is complex or unreliable, pooling creates subtle bugs where stale state leaks between uses.

Use BenchmarkDotNet — it handles JIT warmup, multiple iterations, statistical analysis, and GC pressure measurement automatically. Never measure with Stopwatch in Debug mode or without warmup iterations — the JIT hasn't compiled the hot path yet.

Pitfalls: dead code elimination (the JIT may optimise away code whose result is never used — use Blackhole.Consume()). GC interference (enable MemoryDiagnoser to see allocations per operation). CPU frequency scaling skews results. Always benchmark in Release mode — Debug builds disable inlining and change performance characteristics dramatically.

SIMD (Single Instruction Multiple Data) processes multiple data elements in a single CPU instruction. .NET exposes this through System.Numerics.Vector<T> (portable, auto-vectorised) and System.Runtime.Intrinsics (hardware-specific: SSE2, AVX2, ARM NEON). A Vector<float> can process 8 floats simultaneously on AVX2.

Use cases: bulk mathematical operations, byte searching/parsing (JSON/CSV parsers), checksum/hashing algorithms. The .NET runtime uses AVX intrinsics internally in string.IndexOf and Span.SequenceEqual. Vector<T> gives portable SIMD without hardware-specific code. Real-world gains can be 4–16× for appropriate numeric workloads.

C# doesn't have native discriminated unions, but you can approximate them with a sealed record hierarchy: abstract record Result with subtypes record Success(T Value) : Result and record Failure(string Error) : Result. Pattern matching on the sealed hierarchy is exhaustive.

Methods return Result instead of throwing exceptions for expected failure cases (validation errors, not-found, business rule violations). Callers are forced to handle both branches — error paths become explicit in the type system. This is the Railway Oriented Programming pattern. Reserve exceptions for truly unexpected conditions, not for normal business flow control. The OneOf NuGet package provides a richer generic implementation.

The pipeline is a chain of RequestDelegate functions (Func<HttpContext, Task>). Each middleware receives the current HttpContext and a reference to the next middleware. It can execute logic before calling await next(context), after, or short-circuit entirely without calling next.

To write custom middleware: implement a class with InvokeAsync(HttpContext context, RequestDelegate next). DI is injected via the method parameters (per-request), not the constructor (singleton). Register with app.UseMiddleware<MyMiddleware>(). Key design: middleware that modifies the response must act before the response starts — once headers are sent, you can't change the status code.

Implement BackgroundService and override ExecuteAsync(CancellationToken stoppingToken). The DI container starts it with the host and provides the stopping token at shutdown. Register with services.AddHostedService<MyWorker>().

Reliability: wrap the main loop body in try/catch — an unhandled exception stops the service silently in older .NET versions. For work that must survive crashes, consume from a message queue rather than an in-memory queue that loses data on restart. For scoped DI services (like DbContext), inject IServiceScopeFactory and create a scope per unit of work — background services are singletons and cannot directly inject scoped services.

Classic approach: register multiple implementations, inject IEnumerable<IMyService> and select at runtime. Works but is awkward when you want one specific implementation by name.

Keyed services (.NET 8): services.AddKeyedSingleton<IPaymentGateway, StripeGateway>("stripe"). Inject with [FromKeyedServices("stripe")] IPaymentGateway stripe or resolve via provider.GetKeyedService<IPaymentGateway>("stripe"). This is the clean solution for the Strategy pattern with DI. Before .NET 8, the workaround was a factory delegate or a dedicated resolver service — both add indirection but work across older versions.

Use IExceptionHandler (.NET 8+) — implement the interface, register with services.AddExceptionHandler<MyHandler>() and app.UseExceptionHandler(). Map exception types to ProblemDetails responses (RFC 7807 standard) — consistent JSON with type, title, status, and detail fields.

Register multiple handlers in priority order — the first returning true from TryHandleAsync wins. Map domain exceptions (NotFoundException → 404, ValidationException → 400, ConflictException → 409) and fall through to a 500 catch-all. Never expose stack traces or internal exception messages in production responses. This centralises error handling rather than scattering try/catch blocks through every controller action.

• IOptions<T> — Singleton. Configuration read once at startup and cached forever. Use for settings that never change. Fastest.
• IOptionsSnapshot<T> — Scoped. Re-reads configuration per HTTP request. Use when configuration can change and you want per-request consistency. Cannot be injected into singletons.
• IOptionsMonitor<T> — Singleton. Reads live configuration and provides an OnChange callback. Use in singletons that need to react to config changes (feature flags, rate limit thresholds).

Add validation with ValidateDataAnnotations() and ValidateOnStart() — fails fast at startup if config is invalid rather than crashing at first use in production.

Polly v8 uses a ResiliencePipelineBuilder: chain AddRetry, AddCircuitBreaker, and AddTimeout. Execution order is outer-to-inner: timeout wraps circuit breaker wraps retry wraps the actual operation.

Key configuration: retry with ExponentialBackoff plus jitter to avoid thundering herd (all clients retrying simultaneously). Circuit breaker with FailureRatio threshold and minimum throughput so it doesn't open on a single failure. Register via services.AddResiliencePipeline("http-client", builder => …). For HttpClient, AddStandardResilienceHandler() from Microsoft.Extensions.Http.Resilience configures sensible defaults for all of the above in one call.

Implement IHealthCheck with CheckHealthAsync returning HealthCheckResult.Healthy/Degraded/Unhealthy. Register with services.AddHealthChecks().AddCheck<DatabaseHealthCheck>("database", tags: new[] { "ready" }). Expose with separate endpoints for liveness and readiness.

Key distinction: liveness — is the process alive and not deadlocked? (Simple ping, no external dependencies.) Readiness — is it ready to serve traffic? (Check DB connectivity, cache warming, downstream service reachability.) Kubernetes uses liveness to restart a pod and readiness to decide whether to route traffic. The AspNetCore.Diagnostics.HealthChecks NuGet has pre-built checks for SQL Server, Redis, RabbitMQ, and many others.

[CallerMemberName], [CallerFilePath], and [CallerLineNumber] are applied to optional parameters. The compiler fills them in at the call site with the caller's method name, source file path, and line number — with zero runtime overhead compared to reflection-based approaches.

Practical use: void Log(string message, [CallerMemberName] string method = "", [CallerLineNumber] int line = 0) — callers just write Log("Started") and the logger automatically captures the method name and line. Also used in INotifyPropertyChanged: SetProperty(ref _field, value, [CallerMemberName] string prop = "") means you don't repeat the property name as a string — safer than hardcoded strings and incomparable to reflection overhead.

Before C# 10, logger.LogDebug($"Processing order {orderId}") would always allocate a formatted string even if Debug logging was disabled. Interpolated string handlers allow a method to intercept the string pieces before the string is built — if the logger is not enabled for Debug, it signals "stop" and the string is never constructed.

From .NET 6, LogDebug($"…") is essentially zero-cost when the log level is disabled. This solves the longstanding pattern where developers wrote if (logger.IsEnabled(LogLevel.Debug)) logger.LogDebug(…) as a manual guard. Callers write normal interpolated strings and get the performance for free — it's a compiler feature with no API change required on the caller's side.

Response Caching is header-based (RFC-compliant HTTP caching). It respects Cache-Control headers and is driven by the client — a client can bypass it with a request header. Primarily useful for CDN-cacheable public responses.

Output Cache (.NET 7+) is server-controlled regardless of client headers. It supports tag-based invalidation — cache.EvictByTagAsync("orders") clears all cached responses tagged with "orders" when data changes. Supports vary-by query string/header/claim and custom policies. Use it for authenticated endpoints, briefly cached dynamic pages, or when you need server-side invalidation. The right default choice for most API response caching in modern .NET.

Endpoint filters (IEndpointFilter, .NET 7+) are similar to middleware but scoped to a specific endpoint or route group. They can access strongly-typed endpoint arguments — unlike middleware, which only sees HttpContext. This makes them ideal for validation, logging, or caching logic that needs the parsed body/route parameters.

vs. Middleware: middleware applies globally (or path-prefixed). Filters apply per-endpoint or per-group via AddEndpointFilter(). For cross-cutting concerns affecting all requests (auth, rate limiting, global error handling), use middleware. For endpoint-specific validation that needs typed arguments, use endpoint filters. They compose cleanly with route groups, making it easy to apply a ValidationFilter across an entire API surface without repeating it per route.

NativeAOT (PublishAot) compiles your .NET application to a self-contained native binary ahead of time — no JIT compilation at startup, much faster cold start, smaller memory footprint, and no .NET runtime required on the target machine. Ideal for microservices, CLIs, and containerised lambdas where startup time matters.

Constraints: dynamic code generation and unrestricted reflection are incompatible — you cannot call Assembly.Load, use Activator.CreateInstance without AOT hints, or rely on any code path that generates IL at runtime. Your dependencies must also be AOT-compatible. This is why source generators and [DynamicallyAccessedMembers] annotations exist — they give the trimmer/AOT compiler enough information to preserve what's needed. Many popular NuGet packages still don't support NativeAOT. Validate AOT compatibility with PublishTrimmed first before jumping to NativeAOT.

FrozenDictionary<TKey, TValue> and FrozenSet<T> are read-only collections optimised specifically for lookup performance. At creation time (.ToFrozenDictionary()), they spend extra time building a perfect or near-perfect hash structure specific to the known set of keys. Subsequent lookups are faster than Dictionary because the hash function is specialised and there's no need to handle mutations.

Ideal for: configuration lookups, static mappings (country codes, currency pairs, HTTP status descriptions), permission tables — any collection that's built once at startup and read millions of times. The creation cost is paid once; the lookup savings accumulate over the application's lifetime. Not suitable for any collection that needs to be mutated after creation.

Code that directly calls DateTime.UtcNow or DateTimeOffset.Now is untestable without time travel — you can't control what the clock returns in a unit test. TimeProvider is an abstract class injected as a dependency, with GetUtcNow(), CreateTimer(), and GetElapsedTime() methods. The default implementation delegates to the system clock; tests use a FakeTimeProvider that you advance manually.

This enables deterministic tests for anything time-dependent: token expiry, scheduled jobs, retry backoff calculations, rate limiting windows, and business rules based on dates. The Microsoft.Extensions.TimeProvider.Testing NuGet provides FakeTimeProvider with Advance(TimeSpan) to control the clock programmatically. A simple change with a big impact on testability — always inject time rather than calling the system clock directly.