• Target netstandard2.0 when you must support .NET Framework or older ecosystem consumers that cannot load modern netX assemblies.
• Prefer adding it as part of multi-targeting (net8.0;netstandard2.0) instead of making it your only target for new libraries.
• If all known consumers are modern .NET, target modern netX directly.
  NET Standart

• Start with the modern runtime you deploy and support in production (for example net8.0).
• Add netstandard2.0 only when compatibility requirements are explicit and validated.
• Reassess target frameworks periodically because old compatibility constraints often disappear over time.
  NET Standart

• .NET 5+ unified the platform, so new API evolution happens directly in modern .NET TFMs rather than via new .NET Standard contracts.
• .NET Standard remains a compatibility tool, not the primary innovation target.
• Design choice: optimize for modern .NET first, then add compatibility targets only where business requirements demand them.
  NET Standart

Runtime (CLR), language (C#/F#), and framework libraries (ASP.NET Core, EF Core, extensions).
It matters because most production issues cross layers: a performance problem might involve language-level allocations (C#), runtime GC behavior (CLR), and framework middleware configuration (ASP.NET Core). Understanding the boundaries helps you diagnose root causes instead of applying surface-level fixes.
NET

.NET Framework is Windows-only, ships with the OS, and is in maintenance mode (4.8.x patches only). Modern .NET (.NET 5+) is cross-platform, open-source, and receives active feature development.
Migration matters because new capabilities (Minimal APIs, native AOT, significant performance improvements) only ship in modern .NET. Framework-era patterns (OWIN, System.Web) still appear in legacy codebases that need migration.
NET

The runtime uses tiered JIT compilation (quick startup, then optimized hot paths), the Kestrel web server is built on efficient async I/O (System.IO.Pipelines), and the framework minimizes allocations on the request path.
However, benchmark performance does not automatically transfer to application code — you still need correct async patterns, minimal middleware, and efficient data access to realize it in production.
NET

Put authentication and authorization in the pipeline so endpoints can assume an authenticated principal.
Use middleware for auth and use endpoint metadata and policies to decide access per endpoint.
ASP.NET Web API

JWTs are self-contained and the server stores no record of issued tokens. Revocation requires a server-side blacklist (typically Redis) or very short expiry (15–60 min) combined with long-lived refresh tokens stored server-side and revocable on logout.
Authentication

For browser-based web applications (Razor Pages/MVC) where the browser manages cookie transmission automatically, where session revocation (logout everywhere) is a hard requirement, and where CSRF risk is manageable via ASP.NET Core's built-in anti-forgery tokens.
Authentication

It forces the JWT middleware to verify the token's signature against your known signing key. Without it, a token signed by a different (attacker-controlled) key could be accepted — breaking the entire authentication model.
Authentication

Return 403 when the resource exists but the user lacks permission, and the resource's existence is not sensitive. Return 404 consistently when leaking the resource's existence is a security risk (e.g., private financial or health records).
Authorization

context.Succeed(requirement) marks that requirement as satisfied. context.Fail() explicitly forces authorization failure regardless of other handlers' decisions — it cannot be overridden by a subsequent Succeed. Use Fail only when you have a definitive security reason to block access.
Authorization

Multiple [Authorize] attributes stack with AND semantics — all policies must pass. For OR logic, implement a single custom IAuthorizationRequirement that internally checks whether any of the conditions is met, then apply that single requirement via one policy.
Authorization

No. CORS is a browser enforcement mechanism — it only affects browser-initiated JavaScript requests. Non-browser clients (curl, Postman, server-to-server calls) ignore CORS headers entirely. CORS prevents malicious websites from making cross-origin requests on behalf of a logged-in user (CSRF-style attacks), but it does not replace authentication or authorization. Always secure your API with proper auth regardless of CORS configuration.
CORS

Preflight OPTIONS requests do not carry authentication credentials. If authentication middleware runs first, it rejects the preflight with 401 before CORS headers are added to the response. The browser then sees a failed preflight and blocks the actual request. Placing UseCors() before UseAuthentication() ensures preflight responses include the correct CORS headers and return 200, allowing the browser to proceed with the actual authenticated request.
CORS

A captive dependency occurs when a long-lived service (Singleton) captures a shorter-lived service (Scoped or Transient) at construction time. The shorter-lived service then lives as long as the Singleton, violating its intended lifetime. For DbContext, this causes a single database context to be shared across all requests, leading to data corruption and race conditions.
Dependency Injection

Inject IServiceScopeFactory into the Singleton and call scopeFactory.CreateScope() at the point of use. Resolve the Scoped service from the new scope and dispose the scope when done. This ensures the Scoped service lives within a controlled scope, not captured inside the Singleton.
Dependency Injection

GetService<T> returns null if the service is not registered; GetRequiredService<T> throws InvalidOperationException. Use GetRequiredService<T> in production code where a missing registration is a programming error that should fail loudly at startup rather than silently return null at call time.
Dependency Injection

Expected answer:

• Middleware when concern is app-wide and independent of controller/action internals.
• Action filter when concern needs ActionExecutingContext, action arguments, or action result wrapping.
• Middleware runs earlier in pipeline and can affect all endpoints.
• Filters are more granular for controller/action scope.
  Why this matters: this is a common architecture tradeoff in API design interviews.
  Filters

Expected answer:

• Authorization -> Resource -> Action -> Exception -> Result (with before/after phases where applicable).
• Scope affects order: global, then controller, then action.
• IOrderedFilter can override default order.
  Why this matters: ordering mistakes cause hidden bugs in validation, caching, and error handling.
  Filters

Expected answer:

• Register filter/service in DI container.
• Use ServiceFilter/TypeFilter or options.Filters.AddService<TFilter>().
• Prefer constructor injection and async interfaces.
• Avoid RequestServices.GetService inside filter bodies unless absolutely necessary.
  Why this matters: DI misuse in filters causes brittle code and testing pain.
  Filters

Middleware is pipeline-level and can apply to all requests (before routing/MVC, around endpoint execution). Action filters are MVC-level and run only for MVC actions, with access to action context, model binding, and results; they are a better fit for cross-cutting concerns that are specific to controller actions.
Middlewares

Use a middleware that measures elapsed time around next() and logs it. An action filter works too, but only for MVC actions.
Middlewares

Add a global exception-handling middleware. In ASP.NET Core this is commonly done with app.UseExceptionHandler(...) (and app.UseDeveloperExceptionPage() in development). The handler can log the exception and return a consistent error response (for example, RFC 7807 Problem Details).
Middlewares

A request is received by the host (for example, Kestrel) and then flows through an ordered chain of middleware. Middleware can add features (routing, authN/authZ, CORS, compression, etc.), select an endpoint, and finally execute the endpoint (MVC action, Minimal API handler, etc.). On the way back out, the middleware chain unwinds, allowing post-processing of the response.
Middlewares

C# supports object-oriented (classes, interfaces, inheritance), functional (LINQ, pattern matching, immutable records, expression-bodied members), and procedural styles.
This matters because you can choose the paradigm that fits the problem: OOP for domain modeling, functional for data transformation pipelines, procedural for scripts and glue code.
In API design, mixing paradigms intentionally (e.g., immutable records for DTOs, interfaces for extensibility, LINQ for queries) produces cleaner, more testable code than forcing everything into one style.
CSharp

• Nullable reference types flag potential null dereferences before runtime.
• Generic constraints enforce type relationships without casting.
• Pattern matching with exhaustiveness checks catch missing cases in switch expressions.
• Strong typing prevents accidental type confusion that would be runtime errors in dynamic languages.
  The practical impact: many bugs that surface as runtime exceptions in Python or JavaScript are caught during compilation in C#.
  CSharp

Asynchrony is about not blocking while waiting (especially for I/O). An async method can release the current thread while awaiting, and continue later — potentially on the same thread.
Multithreading is about executing work on multiple threads concurrently (for CPU-bound work). Async code can be single-threaded and still be asynchronous.
The key cost difference: async I/O uses no thread while waiting; multithreading always occupies a thread.
Async Await

await waits asynchronously: it does not block the current thread, it unwraps exceptions as Exception (not AggregateException), and it respects SynchronizationContext.
Task.Result waits synchronously: it blocks the current thread, wraps exceptions in AggregateException, and can deadlock under a SynchronizationContext.
Cost: .Result in a context-aware environment is a deadlock waiting to happen; await is the safe default.
Async Await

In library code that does not need to resume on a specific context. It avoids context-capture overhead and eliminates the deadlock risk when library code is called from a context-aware environment.
Do not use it in application-layer code (controllers, view models) where you need to resume on the original context to update UI or access HttpContext.
Async Await

Because waiting time is no longer paid by tying up worker threads. Released threads can process other requests while I/O is pending. A server with 100 threads can handle thousands of concurrent I/O-bound requests if each thread is released during the wait.
Async Await

For CPU-bound work that you intentionally offload to a pool thread (e.g., image processing, heavy computation). Do not use it to wrap already-async I/O APIs — that wastes a thread for no benefit.
Async Await

When a tiny critical section must complete to keep state consistent — for example, finishing a single idempotent write or releasing resource ownership. The key is that the section is short and bounded. Never hold a lock or do I/O while ignoring a cancellation signal for an extended period.
CancellationToken

Cooperative cancellation stops at known safe points under your control. Thread.Abort (removed in .NET 5+) could interrupt arbitrary code paths — including finally blocks and lock releases — leaving resources or invariants in bad state. Cooperative cancellation keeps control flow explicit and cleanup reliable.
CancellationToken

Pass the token to HttpClient.GetAsync(url, cancellationToken) or equivalent. The HTTP client registers a cancellation callback that aborts the underlying socket. For gRPC, pass the token to the call options. For message queues, check the token between message processing iterations.
Cost: if the downstream service has already started processing, canceling the HTTP call does not cancel the server-side work — only the client-side wait.
CancellationToken

Concurrency is about responsiveness and non-blocking progress, often with async I/O.
Parallelism is about throughput for CPU-bound workloads by using multiple cores simultaneously.
Concurrency and Parallelism

Because thread starvation, deadlocks, lock contention, and unbounded fan-out all manifest as latency spikes and timeouts before obvious crashes.
Concurrency and Parallelism

Classify the workload as I/O-bound vs CPU-bound and define cancellation/error boundaries. Primitive choice follows that classification.
Concurrency and Parallelism

Because it can overload downstream dependencies, saturate connection pools, and create timeout storms. Bounded fan-out keeps latency gains while preserving system stability.
Concurrency and Parallelism

Use lock for short synchronous sections, SemaphoreSlim for async flows that need awaiting, and Channel<T> when you also need queueing, ordering, or backpressure.
Concurrency and Parallelism

Mutual exclusion, hold-and-wait, no preemption, circular wait. Circular wait is easiest to break: enforce a global lock acquisition order across all code paths. This requires discipline but no runtime overhead.
The cost of consistent ordering: you must document and enforce the order, which adds coordination overhead in large codebases.
Deadlocks

UI apps have a SynchronizationContext that marshals continuations back to the UI thread. .Result blocks that thread; the continuation needs it to resume — circular wait.
Console apps and ASP.NET Core have no SynchronizationContext, so continuations resume on any pool thread and .Result merely blocks the calling thread without creating a cycle.
Deadlocks

Capture a process dump with dotnet-dump collect or procdump. Analyze with dotnet-dump analyze and clrthreads/syncblk commands to find threads blocked on monitors. For async deadlocks, look for threads blocked in .Result or .Wait() while holding a SynchronizationContext.
Cost: dump capture briefly pauses the process; plan for a maintenance window or use a non-blocking snapshot tool.
Deadlocks

When you need to coordinate access across multiple processes on the same machine (for example single-writer protection for shared file/database artifacts).
Mutex

It is OS-backed and blocking, so heavy contention can increase latency. In-process patterns (lock, SemaphoreSlim, Channel<T>) are usually more efficient.
Mutex

A previous owner exited without releasing the mutex, which means exclusive ownership was recovered but shared state may be inconsistent and must be validated.
Mutex

Because of contention, synchronization overhead, cache misses, and context switching once you exceed useful core-level parallelism.
Parallelism

Start near Environment.ProcessorCount, then tune with workload benchmarks and production telemetry rather than assumptions.
Parallelism

When correctness depends on strict ordering, side-effect sequencing, or when query-level debugging clarity matters more than terse syntax.
Parallelism

Partitioning, scheduling, and result merge overhead can dominate when per-element CPU work is too small.
Parallelism

Choose SemaphoreSlim when critical sections include await and you need asynchronous waiting. lock cannot contain await safely.
Semaphore

It limits in-flight requests, protecting downstream dependencies and your own resources from overload while preserving concurrency.
Semaphore

Missing or unbalanced Release calls. The safe pattern is acquire then try/finally release in the same method scope.
Semaphore

Task models completion and scheduling, while threads are execution resources. Many async tasks complete I/O without holding a thread during waiting. A single thread can drive thousands of concurrent I/O tasks by processing their continuations sequentially.
Cost of confusing them: over-allocating threads (via Task.Run for I/O) wastes memory and increases context-switching overhead.
Tasks

Rarely for request I/O — async I/O APIs already don't block threads. Use Task.Run for CPU-bound work that must be isolated from the request thread (e.g., image processing, heavy computation), ideally with bounded concurrency via SemaphoreSlim.
Tasks

Sequential await runs operations one after another — total latency is the sum. Task.WhenAll runs them concurrently — total latency is the slowest. For three 100ms calls: sequential = 300ms, concurrent = ~100ms.
Cost: concurrent fan-out can overwhelm downstream services; bound concurrency when calling external APIs.
Tasks

Only when profiling shows allocation pressure from Task on a hot path where the result is frequently synchronously available (e.g., a cache hit). ValueTask has strict consumption rules and is harder to use correctly. Default to Task; switch to ValueTask only with measurement evidence.
Tasks

Starvation means queued work cannot get workers quickly enough. It starts when threads block synchronously (.Result, .Wait(), Thread.Sleep) instead of releasing back to the pool. The hill-climbing algorithm injects new threads slowly (~1 per 500ms), so starvation can persist for seconds under burst load.
Cost of fixing: increasing SetMinThreads reduces ramp-up latency but increases baseline memory usage.
ThreadPool

Because only part of the call graph may be async. Any synchronous segment on a pool thread — a blocking filter, a sync-over-async call in a library, a Thread.Sleep — holds that thread and reduces pool capacity. Even one blocking call per request can starve the pool under high concurrency.
ThreadPool

When you have measured sustained queue depth under burst load and confirmed the bottleneck is thread injection latency (not CPU saturation or I/O). Increase min threads to match your expected burst concurrency. Do not set it higher than needed — each thread costs ~1MB of stack and adds context-switching overhead.
ThreadPool

Task.Run returns a Task that supports await, cancellation, and exception propagation. QueueUserWorkItem is a lower-level fire-and-forget API with no built-in result or error handling. Prefer Task.Run in all modern code; QueueUserWorkItem is a legacy API.
ThreadPool

throw; preserves the original stack trace, while throw ex; resets it to the current method. In practice, this means throw; keeps the real failure path for debugging and observability.
Exception Handling

Wrap when you need to add domain context or translate infrastructure exceptions at a boundary (for example, repository to application service). Keep the original error in InnerException so root cause details remain available.
Exception Handling

A throw in finally can replace the original exception and hide root cause information. The safer pattern is cleanup-only logic in finally, with error handling done in catch or at higher boundaries.
Exception Handling

When the process terminates abruptly and normal stack unwinding does not happen (for example, crash/kill, Environment.FailFast(), or StackOverflowException).
Exception Handling

Any type that implements IEnumerable / IEnumerable<T>, or any type that provides the enumerator pattern (GetEnumerator() + Current + MoveNext()).
Foreach

The compiler lowers it to enumerator code: call GetEnumerator(), loop MoveNext(), read Current.
Foreach

It creates an iterator: each yield return produces a value and pauses the method; the method resumes on the next iteration request.
Foreach

Use yield return for deferred execution and streaming when consumers may stop early or the sequence is large, because it lowers peak memory usage. Materialize (ToList() / ToArray()) when you need a snapshot, random access or Count, or repeated enumeration without rerunning expensive or side-effectful generation logic.
Foreach

IEnumerable<out T> is covariant, so it is safe to upcast because it only produces T values.
List<T> is invariant because it both reads and writes T; if List<string> were assignable to List<object>, code could add a non-string object and break type safety.
In practice, expose covariant interfaces (IEnumerable<T>, IReadOnlyList<T>) at API boundaries and keep mutable concrete collections internal.
Generics

Use out when the type parameter is output-only (returned values), and in when it is input-only (method arguments).
If a parameter must be both consumed and produced, keep it invariant because variance would allow unsafe assignments.
This design choice improves API flexibility without sacrificing compile-time safety.
Generics

default(T) can silently map to meaningful domain values (0, DateTime.MinValue, null), so failures look like valid data instead of explicit errors.
Repeated fallback usage can spread bad state across caches, persistence, or downstream services before detection.
Prefer explicit failure paths (TryXxx, exceptions, discriminated result types) and validate invariants at boundaries.
Generics

Reference type values (the reference) are passed by value. ref is needed when you want the callee to replace the caller's reference (rebind it to a different object).
Methods

To pass an argument by readonly reference: avoid copies for large structs and communicate that the method should not modify the argument.
Methods

Parameters with default values that callers can omit; the default is substituted at compile time at the call site.
Methods

Mark the base member as virtual and the derived member as override. That enables polymorphic dispatch by runtime type. It also means the base API explicitly supports extensibility and behavioral substitution.
Methods

Prefer new only when polymorphism is not desired and you intentionally want different behavior based on the compile-time reference type (for compatibility or specialized APIs). In most extensible designs, override is the safer default.
Methods

Option 1: Change the base API to virtual (best if you own the base type and want polymorphism). Option 2: Hide with new (works, but no polymorphism and can confuse callers). Option 3: Redesign with composition/strategy if inheritance is not a good fit.
Methods

Prefer file-scoped namespaces when a file contains one namespace and regular type declarations, because it reduces indentation and visual noise. Use block-scoped form when a file needs multiple namespace blocks or unusual nesting patterns.
Namespaces

Reflection shifts work from compile time to runtime: member discovery, argument handling, and dynamic dispatch all add overhead compared to direct calls.
The cost is usually acceptable for startup/configuration paths, but on hot paths it compounds quickly.
Practical rule: cache metadata and use compiled delegates when repeated invocation is required.
Reflection

An attribute is metadata attached to code elements (types, methods, properties, parameters).
Frameworks inspect these attributes at runtime (or generation time) to apply conventions like routing, validation, serialization, and test discovery.
Without reflection (or generated equivalents), this metadata would remain passive and unused.
Reflection

Choose reflection when the shape of types/members is unknown until runtime (plugin ecosystems, late-bound tooling, extensibility points).
Prefer interfaces/generics when contracts are known at compile time because they provide stronger safety and better performance.
Prefer source generators in reflection-heavy infrastructure when you need predictable startup, high throughput, or trim/AOT compatibility.
Reflection

Both can define contracts with shared implementation. Key differences:

• State: abstract classes can have instance fields and constructors; interfaces cannot hold instance state (only static fields).
• Inheritance: a class can implement many interfaces but inherit from only one class.
• Access modifiers: abstract classes support protected/internal members; interface members are implicitly public (C# 8+ allows explicit modifiers but no protected instance state).
• Performance: virtual dispatch on abstract class methods is a single vtable lookup; default interface methods may involve additional dispatch overhead.
• Use Case: The default implementation for interface methods have different goal compared to the abstract class implemented methods. While in class, semantically methods providing the basic shared functionality for the delivered classes, that don't have to be overriden. While default implementation exist for making extending the interfaces without breaking the inheritors.
  Classes

No. A static class compiles to an abstract sealed class at IL level — it cannot be instantiated, so there is no object to dispatch interface calls through. Interfaces require an instance for virtual dispatch. If you need a "static implementation" of a contract, the patterns are:

• Use static abstract/virtual interface members (C# 11+) with generics: where T : IMyInterface.
• Use a singleton instance of a regular class that implements the interface.
• Use delegates/Func<T> instead of an interface.
  Classes

Yes, new compiles and hides the sealed method. But the behavior depends on the variable's compile-time type:

class Base { public virtual void Do() => Console.WriteLine("Base"); }
class Middle : Base { public sealed override void Do() => Console.WriteLine("Middle"); }
class Bottom : Middle { public new void Do() => Console.WriteLine("Bottom"); }
Bottom b = new Bottom();

b.Do();           // "Bottom" — resolved at compile time as Bottom.Do

Middle m = b;

m.Do();           // "Middle" — virtual dispatch resolves to Middle.Do (sealed)

Base x = b;

x.Do();           // "Middle" — same virtual dispatch

The new method is completely invisible to polymorphic code. This is almost always a design smell — if you need to change behavior, the method should not have been sealed, or you should use composition instead.
Classes

In C# source code, you cannot write abstract sealed class — the compiler rejects it as contradictory. However, at the IL level, static classes compile to exactly abstract sealed. The CLR treats abstract sealed as "cannot be instantiated and cannot be inherited." So every static class in C# is literally an abstract sealed class in metadata. You can verify this with ildasm or reflection: typeof(Math).IsAbstract && typeof(Math).IsSealed is true.
Classes

Partial classes merge at compile time, and source generators can add members to your type that you do not see in your source file. Dangers:

• Name collisions: a generator adds a method Validate() and you also write Validate() — compile error with a confusing message pointing at generated code.
• Implicit behavior changes: a generator adds INotifyPropertyChanged implementation and overrides Equals. Your tests pass locally but break in CI where a different generator version runs.
• Debugging opacity: stepping through code jumps into generated files that may not be in source control.
• Partial method removal: if a partial method (without accessibility modifier) has no implementing declaration, the compiler silently removes all calls to it. If you forget to generate the body, the call vanishes with no warning.
  Best practice: always inspect generated output (visible in IDE under Dependencies and Analyzers), and write tests that verify generator-dependent behavior explicitly.
  Classes

== compares references by default for classes — two separate new calls produce different heap objects with different references.
Fixes:

1. Override Equals/GetHashCode and overload ==/!= — full manual control, but tedious and error-prone.
2. Implement IEquatable<T> — avoids boxing in generic code and gives a clean Equals(T) method. Still need to overload ==.
3. Use record class instead — the compiler generates value-based Equals, GetHashCode, ==, and != automatically. This is the recommended approach for data-carrier types.
   Classes

The runtime marks the type as permanently broken. Every subsequent attempt to access any member of the type throws a TypeInitializationException wrapping the original exception — even if the condition that caused the failure has been resolved. The type cannot be re-initialized for the lifetime of the AppDomain (or AssemblyLoadContext in .NET Core). This is why static constructors should be kept minimal and defensive because failures are unrecoverable.
Classes

A delegate declaration becomes a sealed type derived from System.MulticastDelegate with Invoke, BeginInvoke, and EndInvoke metadata. Delegate instances carry a target object (or null for static methods), a method pointer, and optionally an invocation list. In modern .NET (6+), calling delegate BeginInvoke/EndInvoke is not supported and throws PlatformNotSupportedException.
Delegates

Iterate GetInvocationList(), cast each entry to the concrete delegate type, invoke in a per-handler try/catch, and optionally aggregate errors. Direct multicast invocation stops at first exception.
Delegates

Direct multicast invocation returns only the last task, so earlier handlers can run unobserved. For async fan-out, iterate GetInvocationList() and await each task explicitly (sequentially or with Task.WhenAll), depending on ordering requirements.
Delegates

An event exposes only add/remove from outside the declaring type. A delegate field can be invoked, replaced, or nulled by external callers. Events preserve publisher ownership of invocation.
Events

The null-conditional form avoids the race where another thread unsubscribes between check and call. It uses a copied delegate reference for the invocation expression.
Events

The publisher keeps strong references to subscriber handlers. If the publisher outlives subscribers, those subscribers cannot be garbage-collected. Prevent with explicit unsubscribe (Dispose), weak-event pattern, or scoped subscription helpers.
Events

No. In modern .NET, EventHandler<T> no longer requires T : EventArgs. You can use any payload type, but EventArgs-based design remains the most idiomatic and interoperable style.
Events

Copy the invocation list using GetInvocationList() and invoke handlers individually in try/catch. Direct event invocation stops at first exception.
Events

Yes — a sees the change. with performs a shallow copy: it copies references, not the underlying objects. Both a.Items and b.Items point to the same List<int> instance. Furthermore, a == b was true before the mutation (same reference in both), but the equality check still uses List<T>.Equals which is reference equality — so it remains true even after the content changes. To get proper deep value semantics, use immutable collections (ImmutableList<T>, ImmutableArray<T>) or override Equals to compare content.
Records

Choose record class when:

• The data contains variable-length reference types (strings, collections) — the struct would not avoid heap allocation anyway.
• The type participates in an inheritance hierarchy (only record classes support inheritance).
• The data is large (more than ~16 bytes of value-type fields) — copy cost outweighs GC cost.
• You need null semantics (e.g. optional return values without Nullable<T>).

Choose readonly record struct when:

• The data is small and all fields are value types — avoids heap allocation entirely.
• You are on a hot path where GC pressure matters (e.g. tight loops, high-throughput pipelines).
• No inheritance is needed.
  Records

Yes — the compiler-generated GetHashCode includes all positional properties regardless of your Equals override. This breaks the contract: two objects that are "equal" (by your custom Equals) may have different hash codes, causing them to land in different buckets in Dictionary, HashSet, or any hash-based collection. Lookups silently fail. Rule: whenever you override Equals, always override GetHashCode to match. The compiler emits a warning (CS8851) if you override one without the other, but it is only a warning — not an error.
Records

Yes, record struct works well as a dictionary key because the compiler generates value-based Equals and GetHashCode by default. Watch out for:

• Mutable record structs — if a key is mutated after insertion, its hash code changes and it becomes unreachable in the dictionary. Use readonly record struct for keys.
• Reference-type properties — if the record struct contains a reference-type property (e.g. string[]), the generated GetHashCode calls that property's GetHashCode, which for arrays is reference-based (not content-based). Two structurally identical keys with different array instances will hash differently. Override GetHashCode or use immutable value-semantic collections.
  Records

• Use StringBuilder for iterative construction (loops, batched appends, streaming transforms) where many intermediate strings would otherwise be allocated.
• Prefer interpolation/concatenation for one-off formatting with a small number of values because readability is usually better.
• In hot paths, benchmark both options and pre-size StringBuilder capacity to reduce buffer growth and copying.
  Strings

• == for strings compares content, while ReferenceEquals checks object identity.
• Two strings can contain identical text but be different objects (for example, literal vs runtime-composed value).
• Use ReferenceEquals only for diagnostics/allocation analysis, not for business equality logic.
  Strings

• Always call APIs that accept StringComparison (string.Equals, StartsWith, EndsWith, IndexOf) instead of culture-implicit overloads.
• Use Ordinal/OrdinalIgnoreCase for identifiers, protocol values, keys, and security-sensitive comparisons.
• Use culture-aware comparison only for user-facing natural-language text where locale behavior is expected.
• Keep the comparison policy explicit and consistent across reads/writes to avoid cross-locale bugs.
  Strings

A readonly struct (or readonly record struct) is the best fit:

• Total payload is roughly 28 bytes before alignment (Guid 16 + DateTime 8 + enum ~4), so it is above the strict 16-byte heuristic and should be benchmarked in your workload.
• Value semantics avoid a separate object allocation per message when values stay inline and are not boxed/captured, reducing GC pressure at 100k/s.
• readonly prevents accidental mutation.
• If the message grows or needs richer behavior/reference sharing, a class can become the better tradeoff.
  Structs

• Property/indexer access usually returns a value copy, not a reference to the original storage.
• Mutating that copy would be discarded immediately, so the compiler blocks common forms (for example CS1612 scenarios).
• Even when a pattern compiles, mutations can affect only the temporary copy, not the original struct instance.
• Mitigate with readonly struct for safer value semantics, or expose ref/ref readonly returns when true by-reference behavior is required.
  Structs

• Default value-type equality is field-by-field and can be expensive in hot paths.
• Depending on type shape/runtime path, equality can include reflection-like overhead and extra indirection.
• Using such structs as keys in dictionaries/sets amplifies the cost because equality and hashing are called frequently.
• Implement IEquatable<T> and override Equals/GetHashCode to define stable semantics and avoid hidden performance costs.
  Structs

• The loop variable was a copy of a value type, so mutations were applied to the copy.
• The same issue appears when mutating structs returned by properties, because property access often returns a copy.
• Fix by making the struct immutable and replacing whole values, or by redesigning to avoid mutable structs in those paths.
• If mutation is required, use APIs with explicit ref semantics very carefully.
  Types

• Boxing happens when a value type is converted to object or interface-typed APIs.
• Each boxing operation allocates and can increase GC pressure in hot paths.
• Prefer generic APIs (List<T>, EqualityComparer<T>, generic interfaces) so calls stay strongly typed.
• Verify with profiling before optimizing, then remove high-frequency boxing boundaries.
  Types

• Use struct for tiny immutable value objects when copy semantics are desired and boxing is controlled.
• Use class for identity-rich entities where reference identity and lifecycle matter.
• Use record class for data-centric models where value-based equality improves correctness.
• Validate the choice against mutation rules, size/copy costs, and equality requirements.
  Types

• It standardized the server-application boundary so middleware/app components were portable across hosts.
• It enabled a composable pipeline model independent of System.Web internals.
• It reduced host lock-in for teams maintaining ASP.NET-era applications.
  OWIN

• No. ASP.NET Core is not OWIN, even though both use middleware pipelines.
• ASP.NET Core uses different abstractions (HttpContext, endpoint routing, hosting model) and has first-class integration with modern .NET runtime/tooling.
• Migration should be treated as conceptual reuse plus API rewrite, not a drop-in protocol swap.
  OWIN

• Prefer incremental migration when downtime risk and release pressure are high; isolate seams (auth, API endpoints, cross-cutting middleware) and move components in slices.
• Prefer rewrite when current architecture blocks critical goals (performance, security posture, operability) and business can fund a transition window.
• Decide with hard constraints: SLA tolerance, test coverage quality, team expertise, and ability to run parallel environments safely.
  OWIN

Use SignalR when you need bidirectional real-time communication (chat, live dashboards, collaborative editing). SignalR abstracts the transport layer (WebSockets with SSE and long polling as fallbacks).
Use server-sent events (SSE) when you only need server-to-client push and want a simpler protocol. Use polling when real-time is not actually needed and you want maximum simplicity and cacheability.
Other

OWIN matters for teams maintaining or migrating legacy ASP.NET Framework applications. Understanding the OWIN middleware pipeline model helps when migrating to ASP.NET Core's similar but distinct middleware pipeline, and when troubleshooting Katana-hosted services still running in production.
Other

• Use SignalR when clients need server-pushed updates with low latency (chat, collaboration, live telemetry).
• It is most valuable when update frequency is high enough that polling wastes bandwidth or increases staleness.
• If updates are rare and latency tolerance is high, simpler HTTP polling can be cheaper to operate.
  SignalR

• Cross-node message fan-out: messages sent on one server do not automatically reach clients connected to another node.
• Plan scale-out early with Azure SignalR Service or a supported backplane, then validate routing under load tests.
• Also validate sticky-session requirements for your chosen topology and transport strategy.
  SignalR

• Groups control message routing, not permission checks.
• Membership can change/rejoin over reconnect paths, so relying on groups alone risks privilege drift.
• Enforce security with authentication and policy/role-based authorization on hub methods.
  SignalR

Managed code runs under the .NET runtime (CLR) and benefits from runtime services like type safety checks, exception handling, garbage collection, and JIT/AOT compilation.
Unmanaged code runs directly as native machine code under the OS (for example, C/C++ binaries). It does not run under the CLR and typically requires explicit resource and lifetime management.
P/Invoke calls into native libraries require marshaling data across the managed/unmanaged boundary, which adds overhead and risks memory corruption if signatures are wrong.
Use SafeHandle (not raw IntPtr) to wrap unmanaged handles — it ensures deterministic release even if exceptions occur and prevents handle recycling attacks.
Tradeoff: interop enables reuse of native libraries and OS APIs, but every boundary crossing costs marshaling overhead and introduces bugs (dangling pointers, double-free) that the GC cannot prevent.
Common Language Runtime

The CLR (Common Language Runtime) is the execution engine of .NET. It loads assemblies, verifies and executes IL, compiles IL to native code (JIT or AOT), manages memory (GC), handles exceptions, supports threading and interop, and provides other runtime services.
IL (also called CIL or MSIL) is the CPU-independent intermediate instruction set produced by .NET language compilers and stored in assemblies together with metadata. The CLR turns IL into native code for the current platform.
JIT compilation adds latency on first method call. Tiered compilation mitigates this: Tier 0 compiles quickly with minimal optimization, then hot methods are recompiled at Tier 1 with full optimization — giving fast startup and high steady-state throughput.
NativeAOT eliminates JIT entirely by compiling to native code at publish time — fastest startup, smallest working set, but no runtime code generation (limits reflection, dynamic assembly loading, and some serialization patterns).
Tradeoff: JIT with tiered compilation is the right default for long-running server workloads; NativeAOT wins for CLI tools, serverless cold-start SLAs, and embedded scenarios where startup and binary size matter more than runtime flexibility.
Common Language Runtime

NativeAOT eliminates JIT startup cost and produces a self-contained native binary — ideal for CLI tools, serverless functions with cold-start SLAs, or embedded scenarios. The cost is longer publish time, larger binary, and loss of runtime reflection-heavy features (dynamic code generation, some serialization patterns). For long-running server workloads, JIT with tiered compilation typically wins on peak throughput.
Common Language Runtime

Most objects die young (short-lived allocations like request-scoped objects). Generational GC exploits this by collecting Gen 0 (newest, smallest) most frequently and cheaply. Long-lived objects are promoted to Gen 1 and Gen 2, which are collected less often. This reduces the cost of GC for the common case while still reclaiming long-lived garbage.
Common Language Runtime

A memory leak is memory that is no longer needed but cannot be reclaimed, so the process keeps growing over time.
Yes, it is possible in .NET:

• Managed leaks: objects stay reachable (for example via static caches, event subscriptions, long-lived collections), so GC cannot collect them.
• Unmanaged leaks: native memory/handles are allocated (directly or indirectly) and not released (for example, missing Dispose() / using).
  Memory Leaks

The call stack is a per-thread LIFO memory region that stores stack frames for active method calls (return address, parameters, locals, etc.).
It can overflow (for example, due to deep or infinite recursion or very large stack allocations). In .NET this typically results in StackOverflowException, and the process is terminated (it cannot be reliably handled).
Memory Leaks

using provides deterministic cleanup for resources that are not just managed memory (file handles, sockets, OS handles, unmanaged buffers). GC runs non-deterministically and does not guarantee timely release of such resources.
The using statement compiles to try/finally so Dispose() is called even when exceptions occur.
Memory Leaks

IDisposable is an interface for explicit, deterministic cleanup via Dispose().
Finalize (a finalizer, written as ~TypeName() in C#) is called by the GC for objects that have a finalizer, but it is non-deterministic and adds overhead. Finalizers should only be used to release unmanaged resources, and Dispose() typically calls GC.SuppressFinalize(this).
Memory Leaks

A standard way to implement IDisposable so both explicit cleanup (Dispose()) and (optionally) finalization are supported.
Typical shape: Dispose() calls Dispose(true) and then GC.SuppressFinalize(this); a finalizer (if needed) calls Dispose(false); Dispose(bool disposing) releases unmanaged resources and, when disposing is true, also disposes managed fields.
Memory Leaks

The GC is the .NET runtime's automatic memory manager for managed objects. It periodically finds objects that are no longer reachable from GC roots, reclaims their memory, and (on the SOH) typically compacts surviving objects to reduce fragmentation.
The GC is generational (Gen 0/1/2): most collections are small and fast, while full collections are less frequent. Generations exploit the generational hypothesis — most objects die young — so collecting Gen 0 frequently and cheaply avoids scanning the entire heap.
Workstation GC (default) runs collections on the allocating thread; Server GC uses dedicated threads per logical processor for higher throughput but more memory overhead.
Background GC (default for Gen 2) allows Gen 0/1 collections to proceed during a long Gen 2 collection, reducing pause times for latency-sensitive workloads.
Tradeoff: Server GC maximizes throughput for multi-core services but uses more memory per heap; Workstation GC minimizes memory footprint for client apps and small containers. Tune based on workload sensitivity to pause duration vs throughput.
Garbage Collector

The SOH stores most objects (typically smaller than ~85,000 bytes) and is compacted regularly.
The LOH stores large allocations (typically 85,000 bytes and above, often large arrays). It is collected with Gen 2 and can become fragmented; compaction behavior differs from the SOH and is more expensive.
Garbage Collector

The CLR loads assemblies, verifies IL safety, JIT-compiles methods on first call (or uses tiered compilation to optimize hot paths later), sets up the GC, and initializes the thread pool.
This matters because startup latency, JIT warmup effects, and thread pool sizing all affect real-world behavior — especially for serverless and containerized deployments with cold starts.
Runtime

GC pauses application threads (in workstation GC) or background-collects (in server GC) to reclaim memory. Gen0/Gen1 collections are fast; Gen2 collections are expensive and can cause visible latency spikes.
Main tuning levers: choose Server vs Workstation GC mode, minimize large object heap allocations (objects over 85KB), reduce Gen2 promotion rates by controlling object lifetimes, and use GC.TryStartNoGCRegion for latency-critical paths.
Always measure with GC event traces (dotnet-counters, PerfView) before tuning — premature GC optimization often makes things worse.
Runtime

Yes. Common causes: event handler subscriptions never unsubscribed, static collections that grow indefinitely, closures capturing references unexpectedly, and finalizer queue stalls blocking reclamation.
These are not OS-level leaks but logical leaks — the GC cannot collect objects that are still reachable through a live reference chain, even if the application no longer needs them.
Runtime

Big O tells you how an approach scales with input size before you build it. A benchmark on 100 items may look fast for both O(n) and O(n²), but at 100K items the quadratic approach is 1000x slower. Big O prevents designs that pass small-scale tests but fail in production.
Benchmarking validates constant factors and real hardware behavior after the algorithmic choice is made.
02 Computer Science

When input sizes are small and bounded (e.g., iterating over 10 HTTP headers), constant factors and cache locality dominate. A theoretically better algorithm with higher overhead (setup cost, memory indirection) can be slower than a simpler one on small inputs.
This is why .NET's Array.Sort uses insertion sort for small subarrays inside its introspective sort implementation.
02 Computer Science

Start with the data structure. The right structure often eliminates the need for a clever algorithm — a HashSet<T> gives O(1) lookup without binary search, a SortedSet<T> gives ordered iteration without explicit sorting. Optimize the algorithm when the structure is fixed by external constraints (e.g., searching within a sorted array from an external source).
02 Computer Science

• An algorithm is a finite, ordered set of steps that transforms input into the required output.
• Time complexity describes how runtime grows as input size increases.
• Space complexity describes extra memory needed as input grows.
• Big O notation is used to compare growth classes independent of hardware details.
• Why it matters: complexity awareness helps avoid implementations that fail under production scale.
  Algorithms

Big O describes asymptotic growth and ignores constant factors, cache locality, branch prediction, and real input distributions. Quick Sort is O(n log n) average like Merge Sort but often faster on arrays due to cache-friendly in-place partitioning.
Measure on representative data after narrowing candidates by complexity class.
Algorithms

Worst-case guarantees behavior under adversarial or degenerate inputs (important for security and SLAs). Average-case describes typical behavior under random inputs. Amortized complexity describes cost spread over a sequence of operations (e.g., dynamic array resizing is O(1) amortized even though individual resizes are O(n)).
Choose based on whether you control the input distribution and whether tail latency matters.
Algorithms

During find(x), path compression rewires every node on the path from x to the root to point directly to the root. This flattens the tree over time, making future find calls on those nodes O(1). Without it, repeated find on a deep tree is O(n) per call.
Cost: a small constant overhead per find call to update parent pointers — negligible in practice.
Disjoint Set Union-Find

Union by rank attaches the tree with smaller rank (approximate height) under the tree with larger rank. This prevents the tree from growing tall, bounding the height at O(log n) before path compression kicks in. Together, the two optimizations achieve O(α(n)) amortized time.
Without union by rank, path compression alone gives O(log n) amortized; without path compression, union by rank alone gives O(log n) worst case.
Disjoint Set Union-Find

Before adding an edge (u, v), call find(u) and find(v). If they return the same root, u and v are already in the same connected component — adding the edge would create a cycle. If different, call union(u, v) to merge the components.
Disjoint Set Union-Find

• Path compression flattens trees during find calls.
• Union by rank prevents tall trees from forming during merges.
• Together they give almost constant amortized time in practice.
• Why it matters: this is the reason DSU scales to large connectivity workloads.
  Disjoint Set

• Connectivity during incremental edge additions in graphs.
• Kruskal minimum spanning tree edge filtering.
• Group merging problems such as account linking and clustering.
• Why it matters: mapping a problem to DSU quickly is a strong interview signal.
  Disjoint Set

Dijkstra

Dijkstra

Dijkstra

• BFS is preferred for shortest path by edge count in unweighted graphs.
• DFS is preferred for deep traversal tasks like cycle detection and topological ordering.
• BFS uses more memory on wide graphs because of the frontier queue.
• Why it matters: choosing the wrong traversal can break correctness or blow memory budgets.
  Graph Algorithms

• Dijkstra assumes once a node is finalized, its best distance is known.
• Negative edges can later produce a shorter route to a finalized node.
• Bellman Ford handles negative edges by repeated relaxation.
• Why it matters: this is a common correctness trap in interviews and real systems.
  Graph Algorithms

Adjacency list is the default for sparse graphs (most real-world graphs): O(V+E) space, efficient neighbor iteration. Adjacency matrix uses O(V²) space but gives O(1) edge existence checks.
Use adjacency matrix only for dense graphs or when you need fast "is there an edge between A and B?" queries. In .NET, Dictionary<T, List<T>> is a common adjacency list implementation.
Graph Algorithms

• The half-split decision depends on monotonic ordering.
• Without sorting, a[mid] < target gives no guarantee about where the target can be.
• Binary search can skip over the target on unsorted input and return false negatives.
• Why it matters: correctness depends on this precondition, so production code should assert or document it.
  Binary Search

• On equality, store mid as a candidate answer.
• Continue searching the left half by setting right = mid - 1.
• Keep the same loop condition and safe midpoint calculation.
• Return the stored candidate after the loop ends.
• Why it matters: this lower-bound variant is a common interview and production requirement.
  Binary Search

• In fixed-width integer languages, left + right can overflow for large index values.
• left + (right - left) / 2 computes the same midpoint without overflow risk.
• The same safety principle applies across many divide-and-conquer algorithms.
• Why it matters: this prevents rare but high-impact correctness bugs at scale.
  Binary Search

KMP (Knuth-Morris-Pratt) Algorithm

KMP (Knuth-Morris-Pratt) Algorithm

KMP (Knuth-Morris-Pratt) Algorithm

DFS BFS

DFS BFS

DFS BFS

Rabin Karp Search

Rabin Karp Search

Rabin Karp Search

• Check whether data is sorted, because that immediately enables Binary Search.
• Identify data shape: array, graph, or text stream, because each has specialized methods.
• Decide whether worst-case guarantees or average speed matters more.
• Why it matters: this quickly narrows the candidate algorithms and prevents wrong assumptions.
  Search Algorithms

• Different algorithms optimize for different constraints such as ordering, memory, and preprocessing.
• Workload shape changes the winner: single lookup, repeated queries, or many patterns.
• Correctness constraints can force specific methods, for example sorted input for Binary Search.
• Why it matters: senior-level decisions are tradeoffs, not memorized defaults.
  Search Algorithms

Bubble sort has O(n²) average and worst-case time with poor cache behavior — each swap touches two adjacent elements, causing many cache misses on large arrays. Insertion sort is strictly better for small arrays (same O(n²) but fewer comparisons and better cache access). For large arrays, introsort (Array.Sort in .NET) is O(n log n). Bubble sort has no scenario where it is the best choice.
Bubble Sort

The early-exit optimization gives O(n) best case on already-sorted input — the same as insertion sort. However, insertion sort achieves this with fewer comparisons and better cache behavior, so even in this case insertion sort is preferred. Bubble sort's main value is pedagogical: it is easy to explain and visualize.
Bubble Sort

For small arrays (n ≤ 20–50), insertion sort outperforms merge sort and quick sort because it has no recursion overhead, no auxiliary memory allocation, and excellent cache locality. This is why Timsort and introsort switch to insertion sort for small partitions — the constant factor advantage outweighs the asymptotic disadvantage.
Insertion Sort

Timsort (Python's and Java's default sort) uses insertion sort for runs shorter than ~64 elements. At that size, insertion sort's O(n²) worst case is bounded (64² = 4096 operations), its cache-friendly sequential access beats merge sort's random access pattern, and it requires no extra memory. The combination of O(n) best case on nearly-sorted data and low constant factors makes it ideal for the small-partition base case.
Insertion Sort

Merge sort requires no random access — it only needs to traverse lists sequentially and re-link nodes. The merge step is O(1) extra space on linked lists (just pointer manipulation, no copy buffer). Quick sort's partitioning requires random access to swap elements by index, which is O(n) on a linked list. For linked list sorting, merge sort is O(n log n) time and O(1) extra space; quick sort degrades to O(n²) or requires O(n) extra space.
Merge Sort

When sorting large datasets in memory-constrained environments: sorting 1 GB of data requires another 1 GB merge buffer. For external sorting (data larger than RAM), merge sort's sequential access pattern is actually an advantage — it maps well to disk I/O. For in-memory sorting where stability is not required and memory is constrained, quick sort (in-place, O(log n) stack) is the better choice.
Merge Sort

O(n²) occurs when every pivot is the minimum or maximum of its partition — each partition step reduces the array by only one element. This happens on already-sorted or reverse-sorted input with a fixed pivot (first or last element). Introsort (.NET's Array.Sort) prevents it by switching to heapsort when recursion depth exceeds 2×log(n), guaranteeing O(n log n) worst case while keeping quick sort's cache-friendly average case.
Quick Sort

Quick sort is in-place — it requires only O(log n) stack space versus merge sort's O(n) auxiliary array. The in-place partitioning accesses memory sequentially, giving better CPU cache utilization. Merge sort's merge step requires copying between arrays, causing more cache misses. For in-memory sorting where stability is not required, quick sort's constant factor advantage typically makes it 20–40% faster than merge sort.
Quick Sort

• Merge sort gives reliable O(n log n) worst-case behavior and stable ordering.
• Quick sort is often faster in practice on in-memory arrays due to cache behavior.
• Quick sort has worst-case O(n^2) if pivot strategy is poor, so randomized or introspective variants are safer.
• Why it matters: this choice affects latency tail risk, memory usage, and correctness when stable ordering is required.
  Sorting Algorithms

• It is strong on very small arrays because constant overhead is tiny.
• It performs well on nearly sorted data where shifts are minimal.
• It is commonly used as a base case inside hybrid production sort implementations.
• Why it matters: knowing this avoids overengineering and explains hybrid sort internals in interviews.
  Sorting Algorithms

.NET uses an introspective sort (IntroSort): it starts with Quick Sort for fast average performance, switches to Heap Sort when recursion depth exceeds a threshold (to guarantee O(n log n) worst case), and uses Insertion Sort for small partitions (to exploit its low overhead on nearly-sorted data).
This hybrid approach demonstrates why production sort implementations combine multiple algorithms rather than using a single one.
Sorting Algorithms

Selection sort scans the entire unsorted suffix to find the minimum, then performs exactly one swap per iteration — n−1 swaps total. This matters when writes are significantly more expensive than reads, such as flash memory with limited write cycles or EEPROM. In those cases, minimizing swaps is worth the O(n²) comparison cost. For RAM-based sorting, the swap count advantage is irrelevant — use insertion sort or Array.Sort instead.
Selection Sort

Selection sort swaps the minimum element into position, which can move an equal element past another equal element. For example, sorting [3a, 3b, 1] by value: the 1 swaps with 3a, giving [1, 3b, 3a] — the relative order of the two 3s is reversed. To make it stable, replace the swap with a shift (like insertion sort does), but that eliminates the O(n) swap advantage. In practice, if stability is needed, use merge sort.
Selection Sort

A data structure is a way to organize related data into a collection-like object. Examples include arrays, lists, queues, stacks, linked lists, dictionaries/hash tables, hash sets, graphs, and trees. .NET provides built-in implementations for many of these (for example Array, List<T>, Queue<T>, Stack<T>, LinkedList<T>, Dictionary<TKey, TValue>, HashSet<T>).
Data Structures

Use List<T> when you need ordered, index-based access and the primary operations are iteration or positional lookup. Use Dictionary<TKey, TValue> when you need fast lookup, insertion, and deletion by a unique key. Use HashSet<T> when you only need membership testing and set operations (union, intersection, difference) without associated values.
The wrong choice shows up as O(n) scans that should be O(1) lookups.
Data Structures

Switching from O(n) linear search to O(1) hash lookup reduces work by orders of magnitude at scale. No amount of loop unrolling or SIMD on the O(n) path matches that.
Focus on algorithmic complexity first, then optimize constant factors within the chosen structure if profiling shows it matters.
Data Structures

Almost never in practice. List<T> (backed by a contiguous array) has better cache locality, lower memory overhead per element, and faster iteration. LinkedList<T> only wins when you need frequent insertions/deletions in the middle of a very large collection and already hold a reference to the node.
In most .NET code, List<T> is the correct default.
Data Structures

A hash table with bucket-based key distribution and collision handling.
Dictionary

It computes a hash and jumps to a bucket instead of scanning each element.
Dictionary

More collisions increase comparisons in a bucket chain and can push operations toward O(n).
Dictionary

No. You usually build graphs using Dictionary, List, HashSet, and Queue/Stack.
Graph

Queue<T> for frontier and HashSet<T> for visited tracking.
Graph

HashSet<T>.Contains is O(1) average; List<T>.Contains is O(n).
HashSet

Because hash/equality contracts are broken (for example, mismatched GetHashCode).
HashSet

The key is hashed, mapped to a bucket, and inserted there. Collisions are handled by chain/probe resolution.
Hashtable

Hashing narrows search to one bucket instead of scanning all entries.
Hashtable

Removing the root breaks heap order. The last node is moved to root and then pushed down through tree levels, which is bounded by tree height.
Heap

A heap guarantees only parent child ordering, not full in order traversal across siblings and cousins.
Heap

It gives efficient dynamic priority scheduling without resorting full collections after each insert.
Heap

Excessive collisions put many keys in the same bucket, so operations must compare more entries.
HashMap

Hash maps rely on hash and equality contracts. If equal keys do not produce equal hashes, lookups can fail. If hashes are poorly distributed, bucket chains grow and performance drops.
HashMap

Dictionary<TKey, TValue> is the default hash map in modern .NET.
HashMap

CPU cache locality dominates many workloads. List<T> keeps data contiguous, while linked-list nodes are scattered and require pointer chasing.
LinkedList

When your algorithm already stores LinkedListNode<T> handles and performs many localized inserts/removes around them.
LinkedList

If code frequently searches by index/value before each operation, you are paying O(n) traversal repeatedly and should usually switch to List<T> or another structure.
LinkedList

List<T> wraps an internal T[] buffer and tracks Count separately from Capacity.
When capacity is exceeded, it allocates a bigger array and copies elements.
List

Count is the number of logical elements. Capacity is the size of the internal array.
List

They usually change only Count. To shrink memory, use TrimExcess() or set Capacity.
List

BFS processes nodes in discovery order by levels. FIFO behavior naturally enforces this traversal order.
Queue

When business correctness depends on priority rather than arrival time, such as shortest-path, scheduler, or SLA-driven dispatching.
Queue

Complexity is not the only risk. If producers outpace consumers, memory grows and latency spikes. Throughput and backpressure design matter more than method complexity.
Queue

It prevents the span from being boxed or moved to the heap, which protects memory safety for references to stack and unmanaged buffers.
Span

Use Memory<T> when the buffer must cross async boundaries, be stored in fields, or live longer than a single synchronous scope.
Span

No. Slice creates another view over the same memory region. This is why spans are useful for allocation-sensitive parsing and protocol handling.
Span

When graph/tree depth may be large or unbounded. An explicit stack avoids blowing the call stack and gives more control over traversal state.
Stack

Work queues usually require FIFO fairness. LIFO processing can starve older items and change expected behavior.
Stack

Push is O(1) amortized. It can be O(n) during resize because elements are copied to a larger internal array.
Stack

SortedSet<T> (and SortedDictionary<TKey, TValue> for key-value scenarios).
Trees

On unknown/deep depth, where iterative traversal with an explicit stack is safer.
Trees

Use Serializable or Repeatable Read. Read Committed (the default in SQL Server and PostgreSQL) allows non-repeatable reads: a balance check and a debit in the same transaction can see different values if another transaction commits between them. For financial calculations or inventory updates, this causes incorrect results. Serializable prevents all anomalies but has the highest lock contention. Repeatable Read prevents non-repeatable reads with lower overhead. Optimistic concurrency (row version/timestamp) is a lighter alternative to Serializable for low-conflict workloads.
ACID

Before applying any change to data pages, the database writes the change to a sequential log file (WAL). The log write is synchronous — the transaction does not commit until the log entry is flushed to durable storage. On crash recovery, the database replays the log to restore all committed transactions and undo any uncommitted ones. WAL makes durability cheap: sequential log writes are fast; the actual data page updates can be deferred (write-behind). This is why databases can commit thousands of transactions per second despite disk I/O.
ACID

Invalidation and correctness. Serving data fast is easy — knowing when that data is no longer valid is the core challenge. You need a clear staleness contract per data type and safe fallbacks for when the cache is unavailable or poisoned.
Caching

Add jitter to expirations so hot keys do not all expire simultaneously. Use request coalescing (singleflight pattern) so only one caller recomputes while others await the result. Consider stale-while-revalidate or background refresh to avoid blocking on recomputation entirely. HybridCache in .NET 9+ handles coalescing automatically.
Caching

Define the correctness target first: read-your-writes for the updating user, plus a staleness budget for everyone else. On the write path, either update the cached value or delete it after the database commit succeeds. If there are multiple writers or async pipelines, publish an invalidation event and consume it in all app instances. For per-user read-your-writes, use a version token in the cache key (row version or updated_at) so the writer reads the new version immediately. Keep a TTL as a safety net for missed invalidations. Add monitoring: rate of stale reads, invalidation lag, and cache hit ratio per key type.
Caching

Add jitter to TTL so expirations spread over time. Add request coalescing so only one request recomputes a key and others await the same result. Consider stale-while-revalidate so you never block on recomputation for hot keys. Add a short circuit to protect the database: rate-limit recomputes, timeouts, and fallback behavior. Identify and treat hot keys separately: shorter payloads, proactive refresh, dedicated cache region.
Caching

Assume a cache key correctness bug until proven otherwise: ensure tenant ID and auth scope are part of every key. Verify there is no shared key for different query parameters, locale, feature flags, or permissions. Ensure you do not cache error pages or partial failures that can later be served as valid results. Use strongly typed key builders and centralized key composition to prevent ad-hoc string keys. Add defense in depth: validate tenant on deserialized payload before returning and log violations.
Caching

Key value or document store.
Use key value if the access pattern is almost entirely by id and you do not need rich querying.
Use document store if you need to read and update an aggregate document (profile + preferences) and occasionally query by a few indexed fields.
NoSQL

When your core use case needs relational constraints and multi-entity transactions, or your queries are fundamentally join heavy.
In that case, add caching, read replicas, or a denormalized read model before switching storage models.
NoSQL

• EF Core takes a snapshot of each loaded entity's property values. On SaveChangesAsync(), it compares current values to the snapshot and generates SQL for changed properties.
• Overhead: change tracking adds memory (snapshot storage) and CPU (comparison on save) per tracked entity.
• Disable with .AsNoTracking() for read-only queries (reports, API responses that don't modify data). This is the single most impactful EF Core performance optimization for read-heavy workloads.
• Tradeoff: .AsNoTracking() entities cannot be modified and saved — you must re-attach them or use ExecuteUpdateAsync() for bulk updates.
  Entity Framework

• N+1 occurs when loading N entities and then accessing a navigation property on each, triggering N additional queries.
• Detection: enable EF Core query logging (LogTo(Console.WriteLine)) or use MiniProfiler/Application Insights to see query counts per request.
• Fix: use Include() for eager loading, or split into two queries and join in memory for large result sets.
• Tradeoff: Include() generates a JOIN, which can produce a large result set if the included collection is large. For collections with >100 items per parent, consider AsSplitQuery() to use separate queries instead of a JOIN.
  Entity Framework

• An index is an auxiliary on-disk structure (usually a B+ tree) that lets the engine seek to rows without scanning the whole table.
• Common types: clustered, nonclustered, unique, composite, filtered, covering (nonclustered with INCLUDE), and columnstore.
• Clustered defines physical row order; nonclustered is a separate structure with a pointer back to the row.
• Columnstore stores data column-by-column for analytics; rowstore B+ tree is for OLTP.
  Indexes

• Key columns participate in B-tree navigation and are subject to the 1700-byte nonclustered key size limit (900-byte for clustered) and the 32-column key limit (SQL Server 2016+).
• INCLUDE columns live only at the leaf level. They bypass both limits and don't affect seek/sort behavior.
• Rule: SARGable columns (used in WHERE, JOIN, GROUP BY, ORDER BY) go in the key; SELECT-only columns go in INCLUDE.
• The goal is eliminating Key Lookup operators in execution plans. Each lookup is a round-trip to the clustered index per row.
  Indexes

• Rebuilding implicitly runs a FULLSCAN statistics update, giving the optimizer accurate cardinality estimates.
• Stale statistics causing a bad plan is a far more common culprit than fragmentation on SSD/cloud storage.
• Test first: run UPDATE STATISTICS ... WITH FULLSCAN without rebuilding. If that fixes the plan, fragmentation was never the issue.
• Rebuilding indexes purely for fragmentation on modern storage is often wasted maintenance work and causes unnecessary blocking.
  Indexes

Normalization eliminates redundancy by decomposing tables so each fact is stored once, preventing update anomalies. Most production OLTP systems stop at 3NF or BCNF because higher forms (4NF, 5NF) address rare anomalies (multivalued and join dependencies) at the cost of more tables and more joins. The decomposition overhead rarely pays off outside temporal or analytical databases.
Normalization Denormalization

Denormalize when a read-heavy workload has expensive joins that indexes can't fix: common in reporting, analytics, or high-throughput APIs. Risks: update anomalies (copies get out of sync), data inconsistency if writes don't update all copies atomically, and increased write complexity. Always measure before denormalizing; premature denormalization adds maintenance cost for no proven benefit.
Normalization Denormalization

2NF eliminates partial dependencies: every non-key attribute must depend on the entire composite primary key, not just part of it. A violation looks like a column that depends on only one column of a multi-column PK. 3NF eliminates transitive dependencies: non-key attributes must depend directly on the PK, not through another non-key attribute. A violation looks like column A depending on the PK, column B depending on A (not on the PK directly). Fixing both involves decomposing the offending columns into separate tables.
Normalization Denormalization

• Read-your-writes: user writes then reads from a stale replica and sees their write missing. Fix: route post-write reads to the leader for a short window, or use LSN/timestamp tracking to wait for the replica to catch up.
• Monotonic reads: user sees newer data on one request, then older data on the next (different replicas). Fix: sticky sessions. Pin the user to the same replica.
• Consistent prefix reads: causally related writes appear out of order (a reply before the original message). Fix: route causally related writes to the same partition so ordering is preserved.
  Replication

• Synchronous: when zero data loss is a hard requirement (financial transactions, audit logs). The leader waits for replica acknowledgment before confirming the write. Cost: every write pays the replica round-trip latency.
• Asynchronous: when write latency matters more than guaranteed durability. Replicas may lag; any unconfirmed writes are lost if the leader crashes.
• Most production systems use async replication with one semi-synchronous replica for failover safety. SQL Server Always On supports both modes per replica. PostgreSQL synchronous_standby_names controls which standbys must confirm before commit.
  Replication

• A network partition isolates the primary from the rest of the cluster. A quorum of remaining nodes elects a new primary. When the partition heals, both nodes believe they are primary and have accepted divergent writes.
• Prevention: quorum-based election. A node must hold a majority of votes to become primary, so only one node can win. Fencing (STONITH) ensures the old primary is forcibly terminated before the new one starts accepting writes, eliminating the window where both are active.
• WSFC uses quorum witnesses; Patroni uses distributed locks in etcd/Consul. Without fencing, quorum alone is not sufficient. A slow primary that loses quorum might still be processing writes for a few seconds.
  Replication

WHERE filters rows before grouping and cannot reference aggregate functions. HAVING filters groups after GROUP BY and can use aggregates like COUNT(*) or SUM(amount). If a condition doesn't depend on an aggregate, always put it in WHERE because it reduces the rows that enter the grouping step.
SQL

A stored procedure executes multi-step logic, can modify data, and returns result sets or output parameters. A function returns a value (scalar or table) and is designed to be called inline in a query. In SQL Server, legacy (non-inlined) scalar UDFs are evaluated row-by-row and can inhibit parallel query plans. SQL Server 2019+ may inline eligible scalar UDFs, avoiding this. Inline table-valued functions (iTVFs) are expanded like macros and don't have the parallelism problem.
SQL

A CTE is a named temporary result set defined with WITH, scoped to a single statement. It improves readability and enables recursive queries for hierarchical data. A CTE is generally treated like an inline view; don't assume it's materialized or reused across multiple references. If you reference the same CTE twice in a query, the optimizer may execute the underlying query twice. For guaranteed reuse of an expensive result, use a temp table instead.
SQL

The five isolation levels are: READ UNCOMMITTED (dirty reads allowed), READ COMMITTED (default, reads only committed data), REPEATABLE READ (re-reading a row returns the same data), SERIALIZABLE (full isolation, highest blocking), and SNAPSHOT (transaction-level consistent snapshot via row versioning in tempdb). Separately, Read Committed Snapshot Isolation (RCSI) is a database-level option (ALTER DATABASE ... SET READ_COMMITTED_SNAPSHOT ON) that makes READ COMMITTED use statement-level row versioning instead of shared locks, eliminating most reader-writer blocking without changing the isolation level name. Switching to READ UNCOMMITTED or NOLOCK is a common anti-pattern: you can read rolled-back, partially-written, or duplicate data.
SQL

Start with the execution plan (SET STATISTICS IO ON or the graphical plan in SSMS). Look for table scans on large tables (missing index), key lookups (a non-clustered index was used but the engine must go back to the clustered index, or the heap via RID lookup, for extra columns; fix by including those columns in the index), and fat arrows indicating large row estimates. Check for stale statistics (UPDATE STATISTICS) when cardinality estimates are wildly off. For repeated slow queries, investigate parameter sniffing: a plan compiled for one parameter value may be terrible for another, fixable with OPTION (RECOMPILE) or OPTIMIZE FOR.
SQL

Shard only when write throughput or storage saturates a single node. Try these first:

• Vertical scaling: operationally trivial, preserves full SQL semantics.
• Read replicas: offload reads but don't help writes.
• Caching: reduces DB load for hot reads.
• Table partitioning: splits data within one server, preserving joins and transactions.

Sharding adds permanent operational complexity and limits cross-shard queries.
[!QUESTION]- Why is shard key choice critical, and what makes a good shard key?
The key determines data distribution and query routing. A bad key causes hotspot shards (uneven load) or scatter queries (fan-out to all shards on every read).

A good shard key has high cardinality, even distribution (avoid sequential IDs with range sharding), query alignment (appears in most WHERE clauses), and stability (changing a key requires moving the row). Common choices: user ID, tenant ID, or a composite of region + entity ID.
[!QUESTION]- How does consistent hashing reduce resharding cost compared to simple modulo hashing?
With hash(key) % N, adding one shard changes N and remaps almost every key, requiring a near-total data migration.

Consistent hashing maps keys and shards onto a circular ring. Adding a shard displaces only the keys between the new shard and its predecessor, roughly 1/N of all keys. Virtual nodes (multiple ring positions per physical shard) prevent any shard from owning a disproportionately large arc.
Sharding

P2P systems have no central authority to act as the source of truth. When peers hold different versions of data and there is no coordinator to resolve conflicts, the system must rely on eventual consistency — peers eventually converge to the same state through gossip or reconciliation protocols. This is acceptable for file distribution (BitTorrent) or content-addressed storage (IPFS) where data is immutable, but it makes P2P unsuitable for systems requiring strong consistency (financial transactions, inventory).
Peer-2-Peer

WebRTC establishes direct peer connections between browsers for audio, video, and data. The challenge is NAT traversal: most browsers are behind NAT and don't have public IP addresses. STUN servers help peers discover their public IP/port. When direct connection fails (symmetric NAT), TURN servers relay traffic. The goal is to minimize relay usage — direct P2P connections reduce latency and server cost; TURN relay is the fallback.
Peer-2-Peer

Split tunneling routes only traffic destined for private resources through the VPN; internet traffic goes directly. Use it to reduce gateway bandwidth cost and latency for internet-bound traffic. Avoid it when corporate policy requires all traffic to pass through security inspection (content filtering, DLP).
VPN

WireGuard is ~4,000 lines of code (auditable by a small team) vs IPsec's ~400,000 lines. Fewer lines means fewer potential vulnerabilities. WireGuard also uses a fixed, modern cryptographic suite (ChaCha20, Curve25519, BLAKE2) with no negotiation — removing cipher selection as an attack vector.
VPN

DNS queries bypass the encrypted tunnel — typically because the OS sends DNS requests to the default interface rather than the VPN interface. Fix: route DNS through the tunnel by setting DNS to an internal server and ensuring DNS requests use the VPN's routing table, or by running a local DNS resolver that forces all queries through the tunnel.
VPN

Because resolvers cache answers for the record's TTL. Old answers persist until they expire. A 24-hour TTL means up to 24 hours of propagation delay. Mitigation: lower TTL to 60–300s before planned changes, then restore it after.
DNS

A recursive resolver (e.g., 8.8.8.8) does the work of walking the DNS hierarchy on behalf of the client. It caches results. An authoritative server holds the actual records for a zone and answers queries about names in that zone. The resolver queries authoritative servers; clients query resolvers.
DNS

DNSSEC signs records with a private key. Resolvers verify signatures using the public key from the DNS hierarchy. A forged response without a valid signature is rejected. Cost: key rotation complexity, signing overhead, and larger DNS responses (signatures add bytes).
DNS

HTTP/1.1 processes requests sequentially per connection — a slow request blocks all subsequent ones. Browsers work around this with 6–8 parallel connections, which is wasteful. HTTP/2 multiplexes many streams on one connection, eliminating application-layer head-of-line blocking and reducing connection overhead.
Cost: a single TCP connection means TCP-layer packet loss affects all streams simultaneously.
HTTP 2

HTTP/2 eliminates it at the application layer but not at the TCP layer. TCP guarantees ordered delivery — a lost packet blocks all subsequent data until retransmitted, stalling all HTTP/2 streams on that connection. HTTP/3 (QUIC over UDP) solves this with per-stream loss recovery.
HTTP 2

When the network has high packet loss (mobile, satellite) and you cannot use HTTP/3 — multiple HTTP/1.1 connections isolate packet loss better than a single HTTP/2 connection. Also when connecting to legacy servers or proxies that don't support HTTP/2.
HTTP 2

Expected answer:

• HttpClient.Dispose() does not immediately release sockets — the OS holds them in TIME_WAIT for ~4 minutes.
• Under load, this exhausts the ephemeral port range → SocketException.
• Fix 1: IHttpClientFactory with default 2-minute handler lifetime — handles both socket pooling and DNS re-resolution.
• Fix 2: singleton HttpClient with SocketsHttpHandler.PooledConnectionLifetime set to force periodic connection recycling.
• Even the singleton approach has a DNS staleness trap without PooledConnectionLifetime.

Why this matters: the most common HTTP production failure in .NET; tests understanding of socket lifecycle and connection pool mechanics.
HTTP

Expected answer:

• no-cache means the response CAN be stored, but the cache MUST revalidate with the origin server before every use via conditional request (If-None-Match or If-Modified-Since).
• no-store means the response MUST NOT be stored at all — not in browser cache, not in CDN, not on disk.
• no-cache is appropriate for content that changes but benefits from 304 responses (saves bandwidth when content has not changed). no-store is for sensitive data like banking pages or PII.
• The naming is misleading — no-cache does not mean "don't cache."

Why this matters: the most commonly misunderstood HTTP caching directive; wrong choice either leaks sensitive data or kills performance.
HTTP

Expected answer:

• 401 Unauthorized means the client is not authenticated — no credentials were provided, or they are invalid. The response MUST include a WWW-Authenticate header.
• 403 Forbidden means the client IS authenticated but not authorized — the server knows who you are, but you lack permission for this resource.
• 401 tells the client to retry with valid credentials. 403 tells the client that retrying with the same identity is pointless.
• Security consideration: some APIs return 404 instead of 403 to avoid revealing resource existence to unauthorized users.

Why this matters: authentication vs authorization is a fundamental security distinction; misusing these codes breaks client auth flows and retry logic.
HTTP

Expected answer:

• Require an Idempotency-Key header for create operations.
• Persist key + request hash + resulting order ID with TTL.
• On retry with same key and same payload, return the original result (201 or 200) instead of creating a new order.
• On same key with different payload, reject with 409 Conflict.
  Why this matters: demonstrates reliability under partial failure and correct non-idempotent write handling.
  REST

Expected answer:

• PUT replaces the target resource representation; repeated identical calls are idempotent.
• PATCH applies partial updates; idempotency depends on patch format and operation semantics.
• Clients can safely auto-retry idempotent requests when network failures are ambiguous.
• Servers should document patch media type and conflict rules (409/422).
  Why this matters: tests precise HTTP semantics and failure-mode reasoning.
  REST

Expected answer:

• Level 2 already provides major REST benefits: resource URIs, verb semantics, status codes, cacheability.
• Level 3 requires hypermedia-aware clients, link relation design discipline, and tooling investment.
• In closed ecosystems, clients often already know workflows, reducing HATEOAS payoff.
• Level 3 is valuable when runtime discoverability and loose client coupling are strategic requirements.
  Why this matters: shows tradeoff thinking rather than dogmatic purity.
  REST

RPC hides the network boundary, but the network introduces failures that local calls never have: calls can time out, be delivered twice (at-least-once delivery), or fail with the server having already executed the operation. A failed RPC does not mean the server didn't execute — the response may have been lost. This forces callers to implement idempotency keys, retries with backoff, and circuit breakers — concerns that don't exist for local calls. The abstraction is useful but must not be trusted blindly.
RPC

Choose gRPC for internal service-to-service communication where: (1) you need high throughput or low latency (binary Protobuf is 3-10x smaller than JSON), (2) you need bidirectional streaming, or (3) you want strongly typed contracts enforced at compile time. Choose REST for public APIs, browser clients (gRPC requires a proxy for browsers), or when human-readable payloads matter for debugging. The key constraint: gRPC requires HTTP/2 and a Protobuf toolchain; REST works with any HTTP client.
RPC

SMTP has no built-in sender authentication — anyone can claim any From address. SPF restricts which IPs can send for a domain. DKIM adds a cryptographic signature that proves the message was not tampered with. DMARC tells receiving servers what to do when SPF/DKIM fail. Without all three, email from your domain will be marked as spam or rejected by major providers.
SMTP

SmtpClient does not support modern authentication (OAuth2), has poor async support, and lacks IMAP/POP3. Microsoft marked it obsolete and recommends MailKit, which supports all modern protocols and authentication methods.
SMTP

Expected answer:

• gRPC multiplexes all calls over a single HTTP/2 TCP connection.
• L4 load balancers distribute at the TCP connection level — they cannot see individual HTTP/2 streams within that connection.
• All calls from one client land on the same backend, defeating load distribution.
• Fix: use an L7 proxy (Envoy, Linkerd, YARP) that terminates HTTP/2 and distributes individual streams across backends. Or use client-side load balancing with service discovery.

Why this matters: the most common production surprise when adopting gRPC; tests understanding of HTTP/2 multiplexing at the transport layer.
gRPC

Expected answer:

• The call has no timeout and can hang indefinitely.
• Resources (threads, sockets, memory) on both client and server are consumed with no bound.
• In a microservice chain, one hanging call can exhaust connection pools upstream, causing cascading failures across services.
• gRPC intentionally has no default deadline because the right value depends on the operation.
• Use EnableCallContextPropagation() to automatically forward deadlines through a service chain.

Why this matters: deadlines are the single most important production gRPC configuration; missing them is the top cause of gRPC-related outages.
gRPC

Expected answer:

• Protobuf binary encoding uses the field number as the wire identifier, not the name.
• Renaming a field changes only the generated code accessor — the wire format is unchanged, so old and new clients interoperate seamlessly.
• Renumbering changes the wire identity — old clients sending the old number will have their data silently interpreted as the new field by the updated server.
• When removing fields, use reserved to prevent the number and name from being reused in future schema changes.

Why this matters: proto versioning is the contract management layer of gRPC; getting it wrong causes silent data corruption that is extremely hard to debug.
gRPC

TCP is a byte stream protocol. The network may deliver data in smaller chunks than the sender wrote. A single ReadAsync call returns however many bytes are available at that moment, which may be less than the full message. Applications must loop until the expected number of bytes is received.
Sockets

Socket is the low-level OS abstraction supporting TCP, UDP, and other protocols. TcpClient wraps a TCP socket and exposes a NetworkStream for stream-based I/O. TcpListener wraps a server-side TCP socket and provides AcceptTcpClientAsync for accepting connections. Use TcpClient/TcpListener for most TCP work; drop to Socket when you need protocol-level control.
Sockets

When latency matters more than delivery guarantees and the application can tolerate or recover from packet loss. Examples: real-time game state updates (stale frames are discarded anyway), DNS queries (fast retry is cheaper than TCP handshake), telemetry/metrics (occasional loss is acceptable). The application must implement its own reliability if needed.
Sockets

• The handshake synchronizes sequence numbers and confirms both sides are reachable before sending data.
• It adds one full round-trip of latency before the first byte of application data can be sent.
• For short-lived connections (single HTTP request, DNS-over-TCP), handshake latency dominates total request time.
• HTTP/2 multiplexing amortizes the handshake across many requests on one connection. QUIC (HTTP/3) eliminates it entirely by combining transport and TLS handshakes.
• Tradeoff: the handshake guarantees reliable connection setup but costs latency — use connection pooling or QUIC when handshake overhead is unacceptable.
  TCP IP

• Flow control protects the receiver: the receive window limits how much unacknowledged data the sender can push.
• Congestion control protects the network: the congestion window limits send rate based on detected packet loss.
• The effective send rate is the minimum of both windows.
• Tuning only one side causes problems: a large receive window with aggressive congestion control still causes network drops; a small receive window with conservative congestion control wastes available bandwidth.
• Tradeoff: flow control is endpoint-local and deterministic; congestion control is network-wide and heuristic — both must be tuned together for optimal throughput.
  TCP IP

UDP when latency matters more than reliability: real-time audio/video, gaming, DNS. A retransmitted old packet is worse than no packet. Applications add their own reliability: sequence numbers for ordering, FEC (Forward Error Correction) for loss recovery, selective retransmission for critical events. QUIC is the canonical example — it builds reliable ordered streams on UDP while avoiding TCP's head-of-line blocking.
UDP

UDP sends at whatever rate the application dictates. Under congestion, UDP traffic doesn't back off — it can starve TCP connections sharing the same link. Applications using UDP for bulk transfer must implement their own congestion control (QUIC does this). For small datagrams (DNS, game state), the impact is minimal because the volume is low.
UDP

QUIC (HTTP/3) implements reliable, ordered, multiplexed streams on top of UDP. It's built on UDP to avoid TCP's head-of-line blocking (a lost TCP segment blocks all streams; QUIC streams are independent), to enable faster connection establishment (0-RTT resumption), and to allow protocol evolution without OS kernel changes. TLS 1.3 is built into QUIC — there's no separate TLS handshake.
UDP

All source code dependencies must point inward — toward higher-level policies (domain). Outer layers (infrastructure, UI) depend on inner layers; inner layers never depend on outer layers. This means you can change databases, frameworks, or delivery mechanisms without touching business rules.
Cost: requires defining interfaces in inner layers and wiring implementations in outer layers — more upfront structure.
Layered Architecture

Traditional layered: UI → Business Logic → Data Access → Database. Changing the DB affects everything above. Onion/Clean: Infrastructure → Application → Domain. The Domain has zero dependencies; Infrastructure implements Domain interfaces. The key difference is dependency inversion at the data access boundary.
Layered Architecture

In MVC, the Controller handles requests and explicitly selects which View to render — the View is passive. In MVVM, the View binds to the ViewModel's observable state — the ViewModel does not know about the View. MVVM enables automatic UI updates via data binding; MVC requires the Controller to pass data to the View on each request.
Cost: MVVM requires binding infrastructure (INotifyPropertyChanged, ICommand) which adds boilerplate; MVC is simpler for stateless request/response flows.
MVC MVVM

The ViewModel has no dependency on HTTP context, routing, or view rendering — it is a plain C# class. You can unit-test it by calling commands and asserting property values. The Controller depends on HttpContext, IActionResult, and the MVC pipeline, requiring more setup or integration tests.
MVC MVVM

Use AssemblyLoadContext to isolate each plug-in's dependencies. Each context has its own assembly resolution scope, so plug-in A's dependency on Newtonsoft.Json 12.x does not conflict with plug-in B's dependency on 13.x. Cost: each context adds memory overhead and prevents type sharing across contexts — objects from one context cannot be cast to types from another.
Plug-in Architecture (MicroKernel)

Treat the extension point interface as a public API with semantic versioning. For breaking changes, introduce a new interface version (IPlugin, IPlugin2) and support both simultaneously via an adapter. Existing plug-ins implement the old interface; new plug-ins implement the new one. The core adapts old plug-ins to the new contract. Cost: adapter proliferation over time — set a deprecation timeline and remove old interfaces after a migration window.
Plug-in Architecture (MicroKernel)

When all features are known upfront and no third-party extensibility is needed. The loading complexity, versioning challenges, and security surface (untrusted code running in-process) are not justified for internal applications. A monolith with feature flags is simpler and safer. Plug-in architecture earns its complexity when customers or third parties need to extend the product without modifying the core.
Plug-in Architecture (MicroKernel)

Expected answer:

• Use gateway routing plus targeted aggregation endpoints for mobile-specific read models.
• Keep gateway concerns to auth, throttling, routing, transformation, and observability.
• Keep business rules, transactions, and domain invariants inside backend services.
• Add correlation IDs and tracing across fan-out calls.
  Why this matters: This tests whether you can design for client efficiency without turning the gateway into a distributed monolith.
  API Gateway

Expected answer:

• Choose a single gateway for simpler systems with similar client needs and shared release cadence.
• Choose BFF when web/mobile/partner clients have materially different payload, auth, or latency profiles.
• Consider team ownership boundaries and deployment autonomy.
• Evaluate operational cost versus client performance and change isolation.
  Why this matters: This reveals whether you can apply tradeoffs, not just name patterns.
  API Gateway

Expected answer:

• Gateway owns north-south concerns: edge auth, TLS termination, external rate limits, API surface control.
• Mesh owns east-west concerns: mTLS, retries, traffic policy, and internal telemetry.
• They complement each other rather than compete.
  Why this matters: Interviewers want clear boundary thinking for platform design decisions.
  API Gateway

• Orders are correctness-critical, so write path should favor consistency (reject/timeout if quorum or primary connectivity is not safe).
• Session cache can favor availability; stale/missing session values are tolerable and recoverable.
• This is an operation-level CAP decision, not contradiction.
• The database remains source of truth; cache is disposable acceleration.
• Tradeoff: it tests whether you can map CAP to business impact instead of reciting definitions.
  CAP theorem

• Because PACELC: without partition, there is still latency vs consistency tradeoff.
• Waiting for more replicas/quorum improves freshness/ordering confidence but increases latency.
• Reading locally reduces latency but may return older data.
• Practical tuning depends on endpoint SLO and correctness requirements.
• Tradeoff: it separates textbook CAP knowledge from real operational design judgment.
  CAP theorem

• Ask for exact conflict resolution policy (last-write-wins, merge function, user-assisted resolution).
• Ask how causality/version metadata is stored and how retries stay idempotent.
• Ask how reconciliation failures are detected (metrics, dead-letter, repair jobs, audits).
• Ask which entities are forbidden from AP behavior (money movement, inventory decrements, security state).
• Tradeoff: senior candidates must translate AP choice into concrete safety controls.
  CAP theorem

Expected answer

• Route post-write reads to strong/session-consistent paths for that user.
• Invalidate or write-through cache on update.
• Include version/timestamp and reject stale follow-up writes.
• Keep write operations idempotent.
  Why this matters: tests whether you can combine storage and cache guarantees without breaking read-after-write UX.
  Consistency Models

Expected answer

• Message ordering/reply chains usually need at least causal consistency.
• Typing indicators can be eventual.
• Compliance-sensitive receipt semantics may justify stronger guarantees.
• Pick by user-visible correctness risk vs latency cost.
  Why this matters: tests whether you can map business semantics to the minimum safe consistency level.
  Consistency Models

Expected answer

• Linearizable paths need coordination/quorum that partitions can block.
• System must reject or delay some operations to avoid conflicting truths.
• Scope strong consistency to critical writes only.
• Serve non-critical reads with weaker models and explicit degraded-mode behavior.
  Why this matters: tests CAP tradeoff reasoning and your ability to design graceful degradation boundaries.
  Consistency Models

• 2PC requires all participants to hold locks during the prepare-to-commit window. In microservices, this window spans network calls, making lock duration unpredictable.
• The coordinator is a single point of failure. A crash after PREPARE but before COMMIT leaves participants locked indefinitely.
• Most microservice infrastructure (HTTP APIs, NoSQL, cloud queues) doesn't support XA transactions.
• Tradeoff: 2PC gives strong consistency but at the cost of availability and throughput. CAP theorem: under a partition, you must choose consistency or availability — 2PC chooses consistency.
  Distributed Transactions

• The event is written to an OutboxMessages table in the same DB transaction as the domain change. If the transaction commits, the event is durable.
• A background worker reads unprocessed outbox entries and publishes them to the broker, retrying until the broker acknowledges.
• This guarantees at-least-once delivery (the event may be published more than once if the worker crashes after publishing but before marking the entry as processed).
• Consumers must be idempotent to handle duplicate events.
• Tradeoff: adds a background worker and an extra DB table. The cost is worth it for any event that must not be lost.
  Distributed Transactions

Expected answer

• Use active probes with failure thresholds and passive error observation from live traffic.
• Mark the instance unhealthy after threshold breach and remove it from new routing.
• Keep it out until it meets consecutive-success recovery checks.
• If ingress is L4 or passive outlier detection is unavailable, rely on active checks plus retry and circuit-breaker policies in clients or gateways.
• Add retries and circuit breakers at the caller or gateway for graceful degradation.
  Why this question matters
• It tests production failure handling, not just basic definition knowledge.
  Load Balancing

Expected answer

• Azure Load Balancer when L4 TCP or UDP distribution is enough and minimal overhead is preferred.
• Azure Application Gateway when L7 HTTP capabilities are needed, such as path routing, WAF, and rich TLS controls.
• Mention that Kestrel typically sits behind one of these ingress layers.
  Why this question matters
• It validates whether the candidate can map requirements to concrete cloud services.
  Load Balancing

Expected answer

• Sticky sessions create uneven distribution and reduce failover quality.
• Scale-out does not fully rebalance existing pinned clients.
• Safer architecture is stateless service instances plus shared session state in Redis or a database.
  Why this question matters
• It checks practical judgment about reliability and elasticity tradeoffs.
  Load Balancing

Expected answer:

• Verify HMAC signature on every incoming webhook to reject forged payloads.
• Use the provider's event ID as an idempotency key; store processed IDs durably.
• Return 200 immediately and process asynchronously from a durable queue.
• Implement reconciliation: periodically call the provider's event list API to detect any missed deliveries.
• Make state transitions conditional (e.g., only transition an order to "paid" if it is currently "pending").
  Why this matters: Tests understanding of at-least-once semantics, idempotency, and defense-in-depth for webhook reliability.
  Webhooks

Expected answer:

• Webhooks when systems cross organizational boundaries and cannot share infrastructure (SaaS integrations, third-party providers).
• Webhooks when the producer is an external system you do not control.
• Message broker when both services are internal, you need durable fan-out, back-pressure, and replay.
• Message broker when you need ordering guarantees per partition/key.
• Hybrid is common: receive external webhooks at the edge and republish to an internal broker for further processing.
  Why this matters: Tests whether the candidate understands the operational boundary between push-over-HTTP and broker-based messaging.
  Webhooks

Expected answer:

• Include a timestamp in the signed payload or as a signed header.
• Verify the timestamp is within an acceptable window (e.g., reject events older than 5 minutes).
• Use the delivery ID as an idempotency key to reject reprocessing even within the time window.
• Verify the HMAC signature covers both the payload and the timestamp so neither can be tampered with independently.
  Why this matters: Tests depth of security thinking beyond basic signature verification.
  Webhooks

Expected answer:

• Use customer_id as partition key so each customer stream stays ordered.
• Provision enough partitions for parallelism based on measured per-partition consumer throughput and latency targets.
• Scale consumer group instances up to partition count.
• Monitor hot partitions and lag; if one customer dominates, consider composite key strategy.
• Keep consumers idempotent because retries and reprocessing can still happen.

Why this question matters: it checks whether the candidate can balance ordering guarantees and horizontal scalability.
Kafka

Expected answer:

• At-most-once risks loss and is rarely valid for payments.
• At-least-once is common if handlers are idempotent and duplicates are acceptable.
• Exactly-once requires transactions and idempotent producer flow, with added latency and complexity.
• For payment events, choose at-least-once plus strict idempotency or exactly-once when duplicate side effects are too costly.

Why this question matters: it tests tradeoff judgment under reliability constraints.
Kafka

MSMQ is appropriate only when: (1) the system already uses MSMQ and migration cost is not justified, (2) the environment is on-premise Windows with no cloud connectivity, or (3) MSDTC-based distributed transactions are required. For all new systems, prefer RabbitMQ (self-hosted, cross-platform) or Azure Service Bus (cloud-managed).
MSMQ

MSMQ is a Windows-only component tied to the .NET Framework. .NET 5+ is cross-platform and does not include Windows-specific legacy APIs. The community MSMQ.Messaging NuGet package provides compatibility, but the recommended path is migrating to a supported broker.
MSMQ

Expected answer:

• Service must be stateless — no in-memory session or local file state.
• All shared state externalized (Redis for cache/session, blob storage for files, database for persistent data).
• A load balancer must distribute traffic across instances.
• Without statelessness, adding instances creates inconsistency rather than capacity.
• Without a load balancer, all traffic still hits one node.
  Why this is strong: It shows horizontal scaling is an architectural property, not just an ops action. Many engineers think "add more servers" is always safe.
  Horizontal Scaling

Expected answer:

• Database becomes the bottleneck — each instance opens its own connection pool (20 instances × 100 pool size = 2,000 connections).
• Stateful services silently break (in-memory session on pod 1 invisible to pod 2).
• Uneven load distribution from sticky sessions or hot partitions.
• Thundering herd during scale-out when new instances aren't ready fast enough.
• Connection pool or thread pool saturation before CPU becomes the bottleneck.
  Why this is strong: It demonstrates awareness that scaling one tier shifts the bottleneck downstream — a classic distributed-systems trap.
  Horizontal Scaling

Expected answer:

• Start with bottleneck identification using telemetry (CPU, DB waits, p95 latency, queue depth, external dependency latency).
• Separate read path and write path capacity constraints.
• Apply highest-ROI pattern first (cache or read replicas for reads, queue for bursty async work, horizontal app scale for compute).
• Re-measure after each change to avoid solving a bottleneck that moved.
• Explicitly discuss reliability and cost impact, not just throughput.
  Why this is strong: It shows methodical scaling based on evidence, not guesswork.
  Scalability Patterns

Expected answer:

• Choose read replicas when main pressure is read throughput on an existing relational model.
• Choose CQRS when read/write models diverge and read projections need different shape or storage.
• Mention consistency behavior: replicas have lag; CQRS read models are eventually consistent by design.
• Mention complexity: replicas are simpler operationally than full CQRS/event projection pipelines.
  Why this is strong: It balances architecture fit, consistency, and operational cost.
  Scalability Patterns

Expected answer:

• When the workload is stateful and hard to shard (e.g., a relational database).
• When the bottleneck is clearly resource-bound on a single node.
• When the operational cost of distributed coordination (consensus, partitioning, eventual consistency) exceeds the cost of a larger machine.
• Vertical scaling is faster to implement and avoids distributed-systems complexity.
• It's the right first move for most monoliths and managed databases in early growth phases.
  Why this is strong: It shows the candidate reasons about tradeoffs (complexity vs cost) rather than defaulting to "just add more servers."
  Vertical Scaling

Expected answer:

• Hardware cost scales super-linearly: premium SKUs charge a multiplier for the same resource increment.
• Not all workloads parallelize across additional cores — Amdahl's Law bounds speedup by the serial fraction.
• A process with 20% serial code can never exceed 5x speedup regardless of core count.
• Memory bandwidth and cache coherency become bottlenecks as core counts grow.
• The cost-per-unit-of-capacity curve inflects sharply at high tiers.
  Why this is strong: It demonstrates understanding of hardware economics and parallelism limits, not just "bigger is better."
  Vertical Scaling

Expected answer:

• A single large node is a single point of failure — any hardware fault, OS crash, or maintenance window causes full outage.
• Vertical scaling increases capacity but does nothing for availability.
• Mitigation: pair with redundancy (active-passive failover, read replicas, multi-AZ deployment).
• Azure SQL Business Critical tier includes a built-in secondary replica for reads and failover.
• This is distinct from Horizontal Scaling, which inherently distributes failure across nodes.
  Why this is strong: It shows the candidate distinguishes capacity from availability — a common interview blind spot.
  Vertical Scaling

When a method returns a value, you know it has no side effects — you can call it freely, cache its result, or call it multiple times without changing state. When a method returns void, you know it changes state but produces no data you depend on. This separation eliminates the need to read the implementation to understand whether a call is safe to repeat or reorder. It also makes testing easier: queries can be tested without checking state changes; commands can be tested without checking return values.
CQS

Three common justified exceptions: (1) Stack.Pop() — splitting into Peek() + Remove() introduces a race condition in concurrent code. (2) Repository.Add() returning the generated ID — the ID is produced by the database; returning it avoids an extra round-trip. (3) Async I/O methods — Task methods that perform I/O and return a result are idiomatic in .NET even when they have side effects. The principle is a guideline: apply it where it improves clarity, relax it where strict adherence creates awkward APIs.
CQS

Expected answer: inject IServiceScopeFactory, create a scope inside startup logic, resolve DbContext from that scope, perform work, dispose scope.
Why: validates practical lifetime-boundary reasoning, not just memorized definitions.
Dependency Injection

Expected answer: transient for lightweight stateless services, scoped for request-bound consistency (DbContext), singleton for thread-safe shared services (cache/config/factory).
Why: checks whether candidate maps lifetime to runtime behavior.
Dependency Injection

Expected answer: it hides dependencies and hurts testability; acceptable in factories, middleware activation, and explicit scope-managed infrastructure.
Why: tests architecture judgment and boundary discipline.
Dependency Injection

• DbContext tracks all changes to loaded entities in its change tracker.
• SaveChangesAsync() wraps all pending inserts, updates, and deletes in a single database transaction.
• This means multiple repository operations within one request share the same DbContext instance and commit atomically — exactly what Unit of Work provides.
• Tradeoff: this only works if all repositories share the same DbContext instance (Scoped lifetime in ASP.NET Core DI). If you accidentally register DbContext as Singleton or Transient, the Unit of Work semantics break.
  Repository & UoW

• A generic repository exposes the same interface for every entity, including operations that don't make sense for some aggregates (e.g., GetAll() on an Order aggregate with millions of rows).
• It encourages callers to treat all entities the same, bypassing aggregate-specific access patterns and invariants.
• It often leaks IQueryable<T>, coupling callers to EF Core.
• Better: aggregate-specific interfaces with domain-meaningful methods. Use a generic base class for the implementation, but expose a specific interface.
  Repository & UoW

Expected answer: CQRS is justified when read/write workloads differ materially (high read ratio, complex query shapes, independent scaling needs) and the domain has meaningful invariants. It is usually an anti-pattern for simple CRUD with low scale pressure, because projection pipelines, eventual consistency handling, and dual-model maintenance add avoidable complexity.
[!QUESTION]- Your dashboard queries are slow because the normalized write model needs 5 JOINs. How does CQRS help, and what is the cost?
Expected answer: CQRS allows a denormalized read model built for that dashboard (for example, a pre-joined projection table), which removes expensive runtime joins and improves latency. The cost is projection infrastructure, eventual consistency, duplicate data, and extra operational work (retries, idempotency, lag monitoring). The key interview point is to justify CQRS only if latency/scaling gains outweigh this complexity.
[!QUESTION]- Does adopting CQRS mean you must adopt Event Sourcing?
Expected answer: No. CQRS is a responsibility split between command and query paths; Event Sourcing is a persistence strategy where events are the source of truth. They fit well together because events project naturally to read models, but CQRS can run on regular state-based persistence (for example, EF Core tables) with or without event publication.
CQRS

• Entity: has a unique identity that persists over time. Two entities with the same data are different if their IDs differ. Example: Order with OrderId.
• Value Object: defined entirely by its attributes, no identity. Two Value Objects with the same data are equal. Immutable. Example: Money(10, "USD").
• Rule of thumb: if you care about which instance it is, it's an Entity. If you only care about what it contains, it's a Value Object.
• Tradeoff: Value Objects are simpler to reason about (immutable, no identity tracking) but require copying on mutation. Use them for concepts like Money, Address, DateRange, Coordinates.
  Domain-Driven Design

• The Aggregate Root enforces all invariants for the cluster. If external code modifies a LineItem directly, it bypasses the Order's consistency checks.
• Example: adding a line item after an order is confirmed should be rejected. If LineItem is modified directly, the Order never gets a chance to enforce this rule.
• Practical implication: repositories load and save entire Aggregates, not individual child entities. EF Core's change tracking makes this natural.
• Tradeoff: loading the full Aggregate for every operation can be expensive if the Aggregate is large. This is a signal that the Aggregate boundary is too wide.
  Domain-Driven Design

• CRUD + audit table can satisfy compliance for many systems with lower operational overhead.
• Event Sourcing is justified when domain behavior depends on historical intent and replay, not only final values.
• If you need deterministic rebuild of multiple read models, Event Sourcing is stronger.
• If temporal queries are frequent and core to product value, Event Sourcing can pay off.
• If team maturity for schema evolution and projection operations is low, choose CRUD first.
• Tradeoff: it tests whether you can choose architecture by constraints instead of defaulting to the most sophisticated pattern.
  Event Sourcing

• Use explicit event versioning strategy.
• Prefer backward-compatible additive changes.
• Introduce upcasters/adapters for old payloads.
• Keep integration tests that replay production-like historical streams.
• Treat event contracts as long-lived public interfaces.
• Tradeoff: schema evolution is a common production failure mode in event-sourced systems, especially when teams skip compatibility testing across historical streams.
  Event Sourcing

Information Expert assigns responsibility to the class that has the information needed to fulfill it. This keeps related data and behavior together, reducing the need for one class to reach into another to get data. The result is lower coupling and higher cohesion — each class does what it knows.
GRASP

GRASP focuses on responsibility assignment — which class should own a behavior or data. SOLID focuses on design principles for maintainability (single responsibility, open/closed, etc.). They are complementary: GRASP guides initial design decisions; SOLID guides refactoring and long-term maintainability.
GRASP

Combine Factory Method (instantiate new robot implementation), Strategy (inject new movement/task behavior), and Template Method (reuse stable execution skeleton).
Expected answer:

• Factory Method for creation extension.
• Strategy for algorithm variation.
• Template Method for stable lifecycle.
• Tradeoff: extra classes and abstraction overhead.
  Why this matters: this question tests OCP-driven design and whether you can combine patterns coherently.
  [!QUESTION]- How do you choose between Strategy and Template Method in robot behavior design?
  Prefer Strategy when behavior slices vary independently and should be swapped by composition. Prefer Template Method when algorithm order is fixed and only selected steps should vary.
  Expected answer:
• Strategy: composition and runtime swap, with more object wiring.
• Template Method: inheritance with a fixed skeleton and tighter base-class coupling.
• Tradeoff: flexibility vs orchestration simplicity.
  Why this matters: this is a common class-design tradeoff where poor choice leads to either rigid inheritance or excessive object churn.
  Design Patterns

• Count 429, 5xx, network, and timeout faults in ShouldHandle.
• Set FailureRatio, SamplingDuration, and MinimumThroughput to match real traffic volume.
• Configure moderate retry with jitter before breaker evaluation.
• On open: fast-fail and switch to fallback (cache, smaller local model, queued async processing).
• Emit breaker state transitions to logs/metrics and page only on sustained open state.
• Tradeoff: it tests whether you can convert noisy provider behavior into explicit resilience policy and graceful degradation.
  Circuit Breaker

• Retry should execute inside the same resilience pipeline before breaker decisions.
• Outer retries around an already open breaker create extra pressure and useless attempts.
• Proper ordering gives cleaner failure accounting and earlier protection.
• Tradeoff: it checks if you understand composition semantics, not just individual patterns.
  Circuit Breaker

• Limit probe concurrency and keep half-open trial volume small.
• Add jitter to retry and recovery timing.
• Use global controls (rate limits, queueing, bulkheads) so per-pod recovery does not synchronize spikes.
• Watch fleet-wide metrics, not only single-instance breaker events.
• Tradeoff: it tests distributed-systems thinking beyond single-process code.
  Circuit Breaker

Expected answer

• Prefer saga/process manager or choreography with explicit failure events (PaymentFailed).
• Avoid direct service-to-service rollback calls as the primary mechanism.
• Emit compensating commands/events (ReleaseInventory, CancelOrder) based on workflow state.
• Keep operations idempotent because retries and duplicates are expected.
• Track workflow with correlation ID for observability and replay.
  Why this is asked
• It tests whether the candidate understands eventual consistency and compensation in distributed systems.
  Event-Driven Architecture

Expected answer

• Choose orchestration when the process is long-running, has strict step ordering, and requires explicit compensation/state visibility.
• Choreography is better when services can react independently and team autonomy is a top priority.
• Orchestration centralizes control (easier reasoning) but adds coordinator complexity and potential bottleneck risk.
• Choreography reduces central coupling but raises tracing and governance complexity as fan-out grows.
  Why this is asked
• It tests architectural judgment under operational constraints, not just pattern definitions.
  Event-Driven Architecture

Expected answer

• Use additive changes first; avoid removing/renaming fields abruptly.
• Version contracts (v1, v2) and support dual publishing during migrations.
• Add consumer-driven contract tests in CI.
• Monitor deserialization failures and rollout with staged deployments.
  Why this is asked
• It tests real-world ownership of compatibility, release safety, and producer-consumer decoupling.
  Event-Driven Architecture

• Each service owns its data, so cross-service business actions cannot rely on one ACID transaction.
• A later step can fail after an earlier local commit, producing partial state.
• Use sagas with compensating actions across local transactions.
• Use outbox/inbox and idempotent handlers to survive retries and duplicates.
• Accept eventual consistency and make process state observable.
  Microservices

• Persist order as Pending and publish OrderPlaced via outbox in the same local transaction.
• Inventory consumes OrderPlaced and emits InventoryReserved or InventoryRejected.
• Order transitions to Confirmed or Rejected based on the inventory event.
• Keep consumers idempotent by tracking processed message IDs.
• Add timeout compensation if inventory does not respond within SLA.
  Microservices

• Decide from team size, release pressure, domain volatility, and ops maturity.
• One team in discovery phase usually benefits most from monolith speed.
• Clear domains with limited platform capacity often fit modular monolith.
• Choose microservices when independent deploy/scale constraints are proven.
• Re-evaluate architecture periodically as constraints change.
  Microservices

A modular monolith enforces explicit module boundaries (clear interfaces, no internal coupling) within a single deployment. It gives you maintainability and team autonomy without distributed systems complexity. It is better than microservices when independent deployment is not yet a hard requirement — which is most early-stage products.
Cost: requires discipline to maintain module boundaries; without enforcement, it degrades into a big ball of mud.
Monolith Architecture

When independent deployment is a hard requirement and the team can support the operational complexity (distributed tracing, network failures, eventual consistency, service mesh). The signal is usually: teams are blocked by each other's deployments, or a specific component needs independent scaling that the monolith cannot provide.
Monolith Architecture

Cold starts occur when the provider scales from zero — the runtime must boot, load the function, and initialize dependencies (500ms–3s for .NET). Mitigations: (1) Premium Plan (Azure) or Provisioned Concurrency (AWS) keeps instances warm at a fixed cost. (2) Native AOT compilation reduces .NET startup time by eliminating JIT. (3) Minimize dependencies loaded at startup — lazy-initialize anything not needed on every invocation. Accept cold starts for background jobs where latency doesn't matter; eliminate them for latency-sensitive APIs.
Serverless Architecture

Isolate business logic from the function host. The function handler should be a thin adapter that reads the trigger event, calls a provider-agnostic service, and returns a response. The core logic lives in a class library with no provider-specific dependencies. This makes the business logic portable even if the host (Azure Functions, AWS Lambda) is not. Cost: requires discipline to keep the adapter thin; teams often let provider-specific bindings leak into business logic.
Serverless Architecture

Serverless: cost = (invocations × duration × memory) + egress. Scales to zero when idle — no cost for unused capacity. Container: cost = (instances × uptime) regardless of traffic. Serverless wins for bursty or infrequent workloads; containers win for steady high-throughput traffic where the per-invocation overhead adds up. The crossover point is roughly when serverless cost exceeds the minimum container cost at sustained load.
Serverless Architecture

SOA uses an Enterprise Service Bus (ESB) as a central integration hub — services communicate through the bus, which handles routing, transformation, and orchestration. Microservices use 'smart endpoints, dumb pipes': services contain the logic and communicate directly via HTTP/REST, gRPC, or lightweight message brokers. The ESB becomes a bottleneck and single point of failure in SOA; microservices distribute that responsibility into the services themselves.
Service-Oriented Architecture

SOA remains appropriate for enterprise integration scenarios: connecting heterogeneous legacy systems (SAP, Salesforce, custom ERP) via a shared integration layer, shared services used by multiple business units where microservice decomposition overhead isn't justified, and regulated industries requiring centralized governance and audit trails. Microservices are better for greenfield cloud-native systems where teams can own independent services end-to-end.
Service-Oriented Architecture

Event-driven architecture is a communication style: components publish events and others react asynchronously. Event sourcing is a persistence pattern: the state of an entity is derived by replaying its event history rather than storing current state. You can use event-driven communication without event sourcing (most systems do). Event sourcing requires event-driven communication but adds the constraint that events are the source of truth for state.
Event-driven

Most message brokers guarantee ordering only within a partition or queue. Kafka guarantees ordering within a partition (use a consistent partition key, e.g., order ID). Azure Service Bus sessions guarantee ordering within a session. Cross-partition ordering is not guaranteed — design consumers to be idempotent and handle out-of-order delivery. If strict global ordering is required, use a single partition (which limits throughput) or a sequencer service.
Event-driven

Most message brokers guarantee at-least-once delivery: a message may be delivered more than once if the consumer crashes after processing but before acknowledging. Without idempotency, duplicate delivery causes double-charging, double-reserving, or duplicate records. Mitigation: track processed event IDs in a ProcessedEvents table and skip duplicates, or design operations to be naturally idempotent (SET stock = X instead of stock -= Y).
Event-driven

• A pure function has no side effects and is referentially transparent: same inputs always produce the same output.
• No side effects means no I/O, no global state reads/writes, no exceptions from external dependencies.
• Testing cost: pure functions need zero mocks — just call with inputs and assert outputs.
• Parallelism: pure functions are safe to run concurrently without locks.
• Tradeoff: real systems need side effects (DB writes, HTTP calls). The FP discipline is to push side effects to the edges and keep the core logic pure.
  Functional Programming

• Shared mutable state is the root cause of race conditions: two threads read-modify-write the same object.
• Immutable objects can be shared freely across threads — no lock needed because no mutation is possible.
• In C#: record types with init-only properties, ImmutableDictionary<K,V>, string (already immutable).
• Cost: every "mutation" allocates a new object. Acceptable for domain events and DTOs; expensive for high-frequency data structures.
• Tradeoff: immutability shifts cost from runtime synchronization to GC pressure. Profile before applying everywhere.
  Functional Programming

• LINQ: when the transformation is a pipeline of filter/map/reduce steps and readability matters more than micro-performance.
• Manual loop: when you need early exit with complex state, when profiling shows LINQ overhead is significant, or when you need to avoid multiple enumerations.
• Key risk with LINQ: deferred execution — materializing with .ToList() at the right point is non-obvious and a common source of double-query bugs.
• Tradeoff: LINQ is more declarative and composable; loops are more explicit about control flow and allocation. In hot paths (>10k iterations/sec), benchmark both.
  Functional Programming

• DI registration: if a service is missing from the container, the integration test fails at startup.
• Middleware ordering: authentication, authorization, exception handling, and routing all run in the real pipeline.
• Serialization contracts: JSON serialization settings (camelCase, nullable handling, custom converters) are applied.
• Controller binding: model validation, route constraints, and action filters run as they would in production.
• Tradeoff: WebApplicationFactory tests are slower than unit tests (seconds vs milliseconds). Run them in a separate test project so they don't slow down the unit test feedback loop.
  Integration Testing

• When your queries use SQL features that EF In-Memory doesn't support: raw SQL, stored procedures, database constraints, RETURNING clauses, CTEs.
• When you need to test database migrations (EF In-Memory doesn't run migrations).
• When a bug was caused by SQL behavior that the in-memory provider masked.
• Tradeoff: Testcontainers requires Docker in CI and adds 5-15 seconds of container startup per test class. The cost is worth it when in-memory tests give false confidence.
  Integration Testing

Prefer composition when the relationship is 'has-a' rather than 'is-a', when you need to combine behaviors from multiple sources (C# has no multiple inheritance), or when the base class is not designed for extension (sealed or has complex invariants). Inheritance creates tight coupling: a change to the base class can break all derived classes. Composition lets you swap implementations at runtime and test components in isolation. Rule of thumb: if you find yourself overriding methods to change or suppress base behavior, composition is the better fit.
OOP

An Anemic Domain Model has objects with only getters/setters and no behavior — all logic lives in service classes. It violates encapsulation: the service must reach into the object to get data, then compute and set results back. This is procedural programming with OOP syntax. The cost: invariants are enforced in service code (scattered, easy to miss), objects can be put into invalid states, and the domain model provides no design guidance. Fix: move behavior that depends on an object's data into the object itself (Information Expert principle).
OOP

Without polymorphism, behavior that varies by type requires if/switch chains: 'if type == PDF, do X; if type == CSV, do Y.' Each new type requires modifying existing code (Open/Closed violation). With polymorphism, each type implements a shared interface and handles its own behavior. Adding a new type means adding a new class, not modifying existing code. The caller iterates over IEnumerable<IReportGenerator> and calls Generate() — the runtime dispatches to the correct implementation.
OOP

• Writing the test first forces you to define the public interface before the implementation exists.
• If the test is hard to write (too many constructor arguments, complex setup), that's a design signal: the class has too many responsibilities or too many dependencies.
• TDD naturally produces smaller classes with single responsibilities because each test targets one behavior.
• Test-after doesn't provide this signal — the implementation already exists and the test is shaped around it.
• Tradeoff: TDD's design benefit requires discipline. Skipping the Red step (writing a test that already passes) eliminates the feedback loop.
  Test-Driven Development

• Exploratory/spike code: you don't know the right design yet. Write the spike without tests, learn from it, then delete it and rebuild with TDD.
• UI rendering logic: visual behavior is hard to unit-test meaningfully; use snapshot tests or manual QA instead.
• Trivial CRUD with no branching: a single-line property setter doesn't need a test-first cycle.
• Tradeoff: TDD overhead is ~20-30% more time upfront. The payback is faster debugging and safer refactoring over the life of the codebase. For short-lived code, the payback never arrives.
  Test-Driven Development

• Inject dependencies as interfaces. In tests, provide a fake or in-memory implementation.
• For repositories: use an in-memory implementation (e.g., Dictionary<Guid, Order>) rather than mocking every method.
• For HTTP clients: use HttpMessageHandler fakes or WireMock.Net for realistic HTTP stubs.
• For time: inject TimeProvider (built into .NET 8+) so tests can control "now" without DateTime.UtcNow coupling.
• Tradeoff: fakes require maintenance. If the real implementation changes behavior, the fake may diverge. Contract tests (testing the fake against the real implementation) catch this.
  Test-Driven Development

• A stub provides canned return values so the test can proceed — it answers questions ("what orders does customer X have?").
• A mock verifies interactions — it records calls and lets you assert that a specific method was called with specific arguments.
• Practical rule: stub data sources (repositories, config); mock side-effect sinks (email, SMS, audit log, event bus).
• Over-mocking (mocking everything including internal collaborators) produces tests that break on every refactor without catching real bugs.
• Tradeoff: mocks couple tests to implementation details. Prefer fakes (working in-memory implementations) when the dependency has non-trivial behavior.
  Unit Testing

• Inject TimeProvider (built into .NET 8+) instead of calling DateTime.UtcNow directly.
• In tests, use FakeTimeProvider (from Microsoft.Extensions.TimeProvider.Testing) to control "now".
• This makes time-dependent logic (expiry checks, scheduling, TTL calculations) fully deterministic in tests.
• Tradeoff: requires changing existing code that calls DateTime.UtcNow directly — a one-time refactor cost that pays off in every time-sensitive test.
  Unit Testing

• Trivial property getters/setters with no logic — the test adds noise without catching real bugs.
• UI rendering logic — visual correctness is better verified with snapshot tests or manual QA.
• Infrastructure wiring (DI registration, config parsing) — test this with integration tests that boot the real container.
• Exploratory spike code — write the spike without tests, learn from it, then delete it before it becomes production code.
• Tradeoff: every test has a maintenance cost. Tests that don't catch real bugs are pure overhead. Focus unit tests on logic with branching, edge cases, and business rules.
  Unit Testing

Duplicated knowledge and duplicated rules.
If a change requires edits in multiple places, DRY is a signal.
DRY

When the repetition is small, the meaning is different, or the logic is expected to diverge.
Local duplication is sometimes safer than a shared abstraction.
DRY

IoC is the principle: the framework controls object creation and wiring instead of your code. Dependency Injection is the most common technique for implementing IoC: dependencies are passed in (injected) rather than created internally. You can implement IoC without DI (e.g., using a service locator or factory), but constructor injection via a DI container is the idiomatic .NET approach. IoC is the what; DI is the how.
IoC (Holywood Principle)

DIP (SOLID 'D') is a design rule: high-level modules should depend on abstractions, not concrete implementations. IoC is a runtime mechanism: the framework wires concrete implementations to those abstractions. DIP is the why (depend on interfaces); IoC/DI is the how (let the container provide the concrete class). You can follow DIP without a DI container by manually wiring dependencies in Main, but a container makes it practical at scale.
IoC (Holywood Principle)

Simple: the design has the minimum number of moving parts needed to meet the current requirements, with clear failure modes and no hidden assumptions. Simplistic: the design ignores real requirements (edge cases, error handling, security) to appear simple. The test: can you explain every component's purpose? If a component exists 'just in case' or 'for future flexibility,' it is probably over-engineering. If a component is missing and the system fails in production, it was simplistic.
KISS

When the complexity solves a proven, current problem: security controls (rate limiting, input validation, authentication) are mandatory for public APIs; retry logic and circuit breakers are mandatory for distributed systems; idempotency keys are mandatory for payment processing. The principle is: add complexity only to solve a proven problem, not a hypothetical one. Complexity that prevents production failures is not over-engineering.
KISS

They are complementary: YAGNI says don't build features you don't need yet; DRY says don't duplicate knowledge; KISS says keep the implementation simple. Tension arises when DRY requires an abstraction that adds complexity (KISS violation) for a single use case (YAGNI violation). Resolution: apply the Rule of Three — abstract when you have two concrete use cases, not one. One use case is speculation; two give you enough information to design a simple abstraction.
KISS

• DIP: code depends on a concrete global instance instead of an abstraction injected via DI.
• SRP: the singleton often mixes business logic with lifecycle and global access concerns.
• OCP: replacing/extending behavior usually requires changing call sites or the singleton itself.
• Fix: expose an interface and let a DI container manage a singleton lifetime.
• Tradeoff: DI adds indirection; singletons are simpler but harder to test and extend.
  SOLID

• Small scripts and prototypes where the overhead of abstractions exceeds the benefit.
• Performance-critical paths where virtual dispatch or interface overhead is measurable.
• When the "correct" abstraction is not yet clear — premature abstraction is worse than duplication.
• Tradeoff: SOLID reduces coupling and improves testability at the cost of more files, more indirection, and more cognitive overhead.
  SOLID

No. YAGNI applies to features and abstractions, not to engineering practices. Martin Fowler explicitly distinguishes: YAGNI says don't build features you don't need yet. It does not say skip tests, skip refactoring, or write messy code. Good engineering practices are always justified because they reduce the cost of future changes.
YAGNI

YAGNI conflicts with design when adding an abstraction now would make future changes cheaper. The resolution: add the abstraction when you have two concrete use cases, not one. One use case is speculation; two use cases give you enough information to design the abstraction correctly. This is the Rule of Three from refactoring.
YAGNI

Blockchain is justified when you need a shared ledger across mutually distrusting parties with no central authority and no single party can be trusted to maintain the record. If all parties trust a central authority, a traditional database with append-only audit logging is simpler, faster, and GDPR-compliant. The cost of blockchain — low throughput, immutability conflicts with erasure rights, consensus overhead — is only worth paying when decentralization is a hard requirement.
Block-chain

Proof-of-Work requires miners to perform computationally expensive hash searches to earn the right to add a block. This energy expenditure is the security mechanism — attacking the chain requires outspending honest miners. Proof-of-Stake replaces energy expenditure with economic stake: validators lock up tokens as collateral and lose them if they act dishonestly. PoS achieves similar security guarantees at a fraction of the energy cost, which is why Ethereum migrated from PoW to PoS in 2022.
Block-chain

The private key is secret — only the signer can produce a valid signature. Anyone with the public key can verify it, but only the private key holder can create it. Reversing this would let anyone forge signatures.
Digital Signature

Signing proves authenticity and integrity — it does not hide the content. Encryption hides the content but does not prove who sent it. TLS uses both: the server certificate is signed (proves identity), and the session data is encrypted (provides confidentiality).
Digital Signature

ECDSA produces shorter signatures (256-bit key gives equivalent security to 3072-bit RSA) and is faster to compute. RSA is still widely used for compatibility, but ECDSA is the modern default for JWT signing (ES256) and TLS certificates.
Digital Signature

Use symmetric (AES-256-GCM) for bulk data encryption — it is 10-100x faster than asymmetric. Use asymmetric (RSA, ECDH) for key exchange and digital signatures, not for encrypting data directly. In practice, use hybrid encryption: asymmetric to exchange a symmetric key, then symmetric for the data. This is exactly what TLS does.
Encryption

Envelope encryption uses two keys: a Data Encryption Key (DEK) encrypts the data; a Key Encryption Key (KEK) encrypts the DEK. The encrypted DEK is stored alongside the ciphertext. The KEK lives in a key management service (Azure Key Vault, AWS KMS) and never leaves it. This pattern is used in cloud storage (Azure Blob Storage, S3 server-side encryption) and allows key rotation without re-encrypting all data — you only re-encrypt the DEK.
Encryption

The algorithm (AES-256-GCM) is well-understood and rarely the weak point. Key management is where systems fail: hardcoded keys in source code, keys stored in plaintext config files, no key rotation policy, no audit trail for key access. Use Azure Key Vault or AWS KMS to store keys, rotate them automatically, and audit every access. Never derive keys from passwords without a proper KDF (PBKDF2, Argon2).
Encryption

• JWT is a compact token format: header.payload.signature (base64url encoded).
• Signed (JWS) means the signature proves integrity and issuer, but the payload is readable by anyone with the token.
• Encryption (JWE) is a separate standard that wraps the JWT in an encrypted envelope.
• Tradeoff: signed-only JWTs are simpler and faster to validate; JWE adds encryption overhead and key management complexity.
  JWT Bearer

• JWTs are stateless — the server cannot revoke them without a blacklist (which defeats the stateless benefit).
• A stolen JWT is valid until it expires. Short expiry (15-60 min) limits the damage window.
• Refresh tokens (stored server-side) allow issuing new JWTs without re-authentication.
• Tradeoff: short expiry requires refresh token infrastructure; long expiry is simpler but riskier.
  JWT Bearer

• A01 (Broken Access Control) is the most prevalent — 94% of tested apps had at least one instance.
• Common .NET manifestation: missing [Authorize] attributes, IDOR (insecure direct object references) where IDs are not validated against the current user.
• A05 (Security Misconfiguration) is also common: developer exception pages in production, missing security headers.
• Tradeoff: fixing access control requires understanding the authorization model, not just adding attributes — resource-based authorization is more work but more correct.
  OWASP

• Use parameterized queries always — EF Core and Dapper with parameters are safe by default.
• Never concatenate user input into SQL strings, even for dynamic ORDER BY or table names.
• For dynamic SQL, use allowlists (validate column names against a known set) rather than sanitization.
• Enable SQL Server's Query Store to detect unusual query patterns.
• Tradeoff: ORMs prevent injection but can generate inefficient queries — use raw parameterized SQL for performance-critical paths.
  OWASP

Base64 is encoding, not encryption — it is trivially reversible. Over HTTP, the Authorization header is sent in plaintext and visible to any network observer. Over HTTPS, the header is encrypted by TLS, making Basic Auth safe to use.
Basic Auth

For machine-to-machine calls between trusted services on an internal network over HTTPS, Basic Auth is acceptable when simplicity matters and the credential is a service account (not a user password). For user-facing authentication, use OAuth 2.0 / JWT Bearer — Basic Auth requires sending credentials on every request, which increases exposure.
Basic Auth

• OAuth 2.0 is an authorization framework: it grants access to resources (what you can do).
• OIDC is an authentication layer on top of OAuth 2.0: it proves who the user is.
• OAuth 2.0 issues access tokens; OIDC additionally issues ID tokens (JWTs with user claims).
• Tradeoff: OIDC adds the ID token and UserInfo endpoint; OAuth 2.0 alone cannot tell you who the user is.
  Oauth OIDC (OpenId Connect)

Role-based authorization checks what type of user you are (e.g., Admin, Editor). Resource-based authorization checks your relationship to a specific resource instance (e.g., are you the owner of this document?). Use role-based for coarse-grained access control; use resource-based when the decision depends on data.
Resource-based Auth

IAuthorizationService centralizes authorization logic in handlers, making it testable and reusable across controllers. Direct ownership checks in controllers scatter authorization logic, making it easy to miss a check or apply it inconsistently. The handler pattern also supports multiple requirements composing into a single policy.
Resource-based Auth

SSO eliminates repeated interactive logins across applications — users authenticate once and access many services. It does not replace per-application authorization (what the user can do) or per-application session management (how long the session lasts). Each application still manages its own session and access control.
SSO (Single Sign-On)

Signature (using IdP's public key), issuer, audience (your client_id), expiry, and nonce. Also validate the redirect URI matches the registered value. Missing any of these opens the door to token forgery, replay attacks, or open redirect vulnerabilities.
SSO (Single Sign-On)

When integrating with legacy enterprise IdPs that only support SAML (older ADFS, some SaaS products). For new systems, OIDC is simpler, better supported on mobile/SPA, and has a richer ecosystem of libraries. The cost of SAML: XML parsing complexity, larger message sizes, and harder debugging.
SSO (Single Sign-On)

TOTP codes can be phished — an attacker can trick a user into entering their code on a fake site. FIDO2 keys are bound to the origin domain: the browser only uses the key for the exact domain it was registered on, making phishing impossible. The private key also never leaves the device.
Two-Factor Auth

TOTP is simpler to implement and works on any device with an authenticator app — use it for most applications. FIDO2 is phishing-resistant and required for high-assurance scenarios (banking, admin access, NIST AAL3). The cost is hardware dependency and more complex enrollment flow.
Two-Factor Auth

BDD adds overhead: Gherkin scenarios must be written and maintained, step definitions must be kept in sync, and the collaboration process takes time. The overhead is not worth it for: pure technical components with no business language (algorithms, infrastructure), small teams where developers and stakeholders communicate directly without formal scenarios, and rapidly changing requirements where maintaining .feature files becomes a burden. BDD earns its cost when: business rules are complex and misunderstanding them is expensive, cross-functional alignment is genuinely needed, and scenarios serve as living documentation.
BDD

TDD focuses on unit behavior: does the code work correctly? Tests are written by developers in code. BDD focuses on system behavior: does the system meet requirements from the user's perspective? Scenarios are written in business language (Gherkin) collaboratively with stakeholders. They are complementary: use TDD for unit-level design and fast feedback loops; use BDD for acceptance criteria and cross-functional alignment. A well-tested system uses both — TDD for the inner loop, BDD for the outer loop.
BDD

Specification by example replaces abstract requirement statements ('the system should handle invalid input') with concrete examples ('given a blank email field, when I submit the form, then I see the error message X'). Concrete examples are unambiguous: they can be automated as tests and verified against the running system. Abstract requirements are interpreted differently by developers, testers, and business stakeholders. The Three Amigos practice (developer + tester + business) produces examples collaboratively, surfacing misunderstandings before implementation begins.
BDD

Hours are absolute and vary by person, day, and context. A senior engineer estimates 2 hours; a junior estimates 8 hours for the same task. Story points measure relative complexity: a 5-point story is roughly twice as complex as a 2-point story, regardless of who does it. A team's velocity (points per sprint) emerges from historical data and automatically accounts for team-specific factors like skill level, interruptions, and tech debt. Treating story points as hours destroys this abstraction and makes velocity meaningless.
Estimation Techniques

Treating story points as hours ('8 points = 8 hours'). This forces estimators to think in absolute time, reintroduces the person-dependency problem, and makes velocity comparisons between teams meaningless. The fix: calibrate story points against reference stories ('this is a 2-point story because it's similar to the login feature we built last sprint'), track velocity over 3-5 sprints to establish a baseline, and use that baseline for capacity planning — never convert points to hours.
Estimation Techniques

Use GitHub Actions when your code is on GitHub and you want zero infrastructure overhead — it integrates natively with PRs, branch protection, and OIDC for cloud auth. Use Azure DevOps Pipelines when deploying to Azure services (AKS, App Service, Azure Functions) and needing enterprise features: approval gates, deployment environments, audit trails, and integration with Azure Boards. Both support .NET equally well; the decision is about ecosystem fit and operational requirements.
CI CD tools

A good CI pipeline: (1) runs in < 10 minutes (fast enough to not block the developer), (2) has zero flaky tests (every failure is a real failure), (3) masks secrets and never logs sensitive data, (4) promotes the same artifact through environments (no rebuilds), (5) has clear failure messages that point to the root cause. A fast but unreliable pipeline trains developers to ignore failures and re-run instead of fix — which defeats the purpose of CI.
CI CD tools

• The .NET SDK image (~800MB) includes compilers and build tools not needed at runtime.
• The ASP.NET runtime image (~200MB) is sufficient for running the published app.
• Multi-stage builds copy only the published output to the final image, reducing size by ~75%.
• Smaller images mean faster pulls, less attack surface, and lower registry storage costs.
• Cost: slightly more complex Dockerfile; worth it for any production workload.
  Docker

• Never use ENV or ARG for secrets in Dockerfiles — they are visible in docker history.
• Pass secrets at runtime via environment variables (docker run -e) or Docker secrets.
• For build-time secrets (e.g., NuGet feeds), use RUN --mount=type=secret (BuildKit).
• In Kubernetes, use Secrets mounted as environment variables or files.
• Tradeoff: runtime injection adds operational complexity but is the only safe approach.
  Docker

• Pod: the smallest unit; wraps one or more containers sharing a network namespace.
• Deployment: manages a set of identical pods; handles rolling updates and scaling.
• Service: stable network endpoint (DNS name + IP) that load-balances across pods.
• Pods are ephemeral (new IP on restart); Services provide stable addressing.
• Tradeoff: Deployments add a layer of abstraction over pods, but that abstraction enables zero-downtime updates.
  Kubernetes

• Base64 is encoding, not encryption — anyone with etcd access can decode secrets trivially.
• By default, etcd stores secrets in plaintext (base64 is just a transport format).
• Mitigations: enable etcd encryption at rest, use Sealed Secrets (encrypted in git), or use Azure Key Vault with the Secrets Store CSI driver.
• Tradeoff: external secret management adds operational complexity but is required for regulated workloads.
  Kubernetes

• CrashLoopBackOff means the container starts, crashes, and Kubernetes keeps restarting it with exponential backoff.
• Common causes: app crashes on startup (missing config, DB connection failure), liveness probe failing before app is ready, OOMKilled (memory limit too low).
• Debug: kubectl logs <pod> --previous (logs from the crashed instance), kubectl describe pod <pod> (events and exit codes), kubectl exec -it <pod> -- /bin/sh (if the container starts briefly).
• Tradeoff: liveness probes are essential for self-healing but misconfigured probes cause the problem they are meant to solve.
  Kubernetes

• Start from traces to find which span dominates p95/p99 latency on slow requests.
• Correlate with RED metrics per service to confirm whether latency is isolated or systemic.
• Check dependency spans (DB, cache, external API) to identify downstream propagation.
• Use structured logs with the same trace ID to validate edge-case payloads or retries.
• Why this answer is strong: it uses all three pillars together instead of guessing from one dashboard.
  Observability

• Use RED for customer-facing service endpoints and request pipelines.
• Use USE for underlying resources such as CPU, thread pools, queue depth, and DB connections.
• Combine both: RED shows symptom at service boundary; USE explains pressure source beneath it.
• Why this answer is strong: it separates service health from resource health and links them causally.
  Observability

• Early instrumentation bakes telemetry into contracts and code paths before scale complexity appears.
• Retrofitting often misses historical baselines and requires invasive code changes across many services.
• Vendor-neutral instrumentation preserves backend flexibility as platform needs evolve.
• Why this answer is strong: it explains operational risk, engineering cost, and architecture flexibility.
  Observability

• Blue-green gives instant rollback by switching traffic back to the old environment, but requires running two full environments simultaneously.
• Canary gradually shifts traffic to the new version, catching issues in production with real users before full rollout.
• Choose canary when you need production validation with real traffic patterns that staging cannot replicate.
• Choose blue-green when you need atomic cutover and can afford double infrastructure cost during the switch.
• Canary requires traffic splitting infrastructure (service mesh, load balancer rules, or a progressive delivery controller like Argo Rollouts).
• Tradeoff: canary reduces blast radius but extends the deployment window and requires monitoring automation to detect regressions; blue-green is simpler but doubles infrastructure cost during deployment.
  Deployment Strategies

• Rolling deployments run old and new code side by side during the rollout window.
• A destructive schema change (dropping a column, renaming a table, changing a constraint) breaks the old instances still serving traffic.
• Safe approach: expand-and-contract migrations — add the new column first, deploy code that writes to both, then remove the old column in a later release.
• If schema changes are not backward-compatible, rolling deployment causes partial failures, data corruption, or 500 errors from old instances.
• Tradeoff: expand-and-contract adds migration complexity and requires multiple deployment cycles, but it is the only safe path for zero-downtime schema evolution with rolling deploys.
  Deployment Strategies

• Canary validates operational health — does the new version crash, timeout, or degrade throughput.
• A/B testing validates user behavior — does the new version improve conversion, engagement, or other business metrics.
• Use canary first to confirm the release is safe, then A/B test to measure business impact.
• A/B testing requires statistically significant traffic volumes and longer observation windows than canary health checks.
• Canary can auto-rollback on error rate spikes in minutes; A/B tests typically run days or weeks.
• Tradeoff: combining both gives the most confidence but requires traffic management infrastructure, metric pipelines, and longer release cycles — justified for high-impact user-facing changes, overkill for internal services.
  Deployment Strategies

GitFlow's long-lived develop branch accumulates divergence from main over days or weeks. Feature branches branch off develop, so they also diverge. When multiple features merge back, conflicts compound. The release/* stabilization phase adds a manual gate that prevents continuous deployment. For web services that deploy multiple times per day, GitFlow's overhead is pure cost with no benefit. Use trunk-based development or GitHub Flow instead.
Branching Stratagies

Trunk-based development requires: (1) feature flags to hide incomplete features from users, (2) fast CI (< 10 minutes) so broken commits are caught quickly, (3) team discipline to keep commits small and the trunk green. Without feature flags, incomplete features must be fully hidden behind code-level conditions or held back entirely. Without fast CI, a broken commit blocks the whole team. Teams without these practices should start with GitHub Flow (short-lived PRs) and evolve toward trunk-based as their CI matures.
Branching Stratagies

With IaaS you manage the OS, runtime, and middleware — you patch the OS, configure security groups, and handle scaling policies. With PaaS the provider manages all of that; you only deploy application code and data. The tradeoff: IaaS gives full control (custom OS, GPU, specific runtime versions); PaaS eliminates operational overhead at the cost of flexibility. Start with PaaS for new web applications; move to IaaS only when PaaS cannot meet your requirements.
IaaS, PaaS, SaaS, CaaS

CaaS (e.g., AKS, EKS) sits between them: you manage container images and deployments, but the provider manages the Kubernetes control plane and underlying OS. It gives more control than PaaS (you define your own container images, resource limits, and networking) while eliminating the Kubernetes control plane management burden of IaaS. Use CaaS when you need container portability or multi-service orchestration that PaaS cannot provide.
IaaS, PaaS, SaaS, CaaS

Use the dimensions parameter to truncate vectors to 256 or 512 dimensions. Models trained with Matryoshka objectives produce vectors where any prefix is independently meaningful. Truncation to 256 dims reduces storage by ~6x and speeds up ANN search proportionally. Validate by comparing recall@k on your evaluation set at 256, 512, and full dimensions — MRL models can retain strong retrieval quality at reduced dimensions, but the actual degradation is model-specific and corpus-dependent. If recall drops unacceptably, use a two-stage approach: retrieve at reduced dimensions, then re-rank candidates using full-dimensional vectors.
Embeddings

Different embedding models produce vectors in different geometric spaces — cosine similarity between vectors from two different models is meaningless. If the corpus is not re-embedded with the new model, queries encoded with the new model are compared against vectors from the old model, producing degraded or random rankings. The fix is to re-embed the entire corpus with the new model before switching query-time inference. This is also why embedding caches must key by model name and version.
Embeddings

Finetuning is justified when retrieval failures are specifically caused by semantic mismatches on domain terminology — queries and relevant documents contain the same domain concepts but land far apart in vector space. If failures trace to split logical units (chunking issue), missing metadata filters (retrieval pipeline issue), or query ambiguity (query translation issue), finetuning the embedding model will not help. Diagnose by examining the top-k retrieved chunks for failed queries: if semantically relevant chunks exist but rank low, the embedding model is the bottleneck.
Embeddings

Both reshape the same token probability distribution but through different mechanisms. Temperature scales the logit distribution (sharpening or flattening), while top_p truncates it to a cumulative mass threshold. Changing both creates unpredictable interactions — a low temperature already concentrates probability mass, so a low top_p on top of it may have no additional effect, while a high temperature with a low top_p creates conflicting signals. Tuning one while keeping the other at default keeps behavior predictable.
Generation

Models can attach citation markers to claims without verifying entailment. The citation looks correct but the cited passage may not actually support the claim — it may be topically related but not evidentially sufficient. This is why citation generation alone is not grounding: a separate claim-to-source verification step (NLI or similar) is needed to confirm that each cited passage actually entails the claim it is attached to.
Generation

Constrained decoding enforces a specific JSON schema at the token level during generation — the output is structurally compliant by construction. JSON mode only guarantees valid JSON without schema enforcement, so the model can return any valid JSON structure. Use constrained decoding when downstream systems depend on a specific schema (API contracts, database inserts, tool arguments). Use JSON mode when you want parsable output but the structure is flexible or exploratory.
Generation

(1) Allowlisted tools/actions only, (2) strict output schema validation, (3) PII scanning on outputs, (4) prompt injection detection on inputs, (5) an abstention/escalation path for uncertainty. These five controls catch the most common failure modes at low cost. Add content safety classifiers and human-in-the-loop for high-risk domains.
Guardrails

No. Filters help with known bad patterns but miss novel attacks, indirect injections, and context-dependent harms. You still need least-privilege tool access, structured outputs, and tests for injection and data exfiltration. Defense in depth is the only reliable approach.
Guardrails

Build a red-team test suite: injection attempts ("ignore all previous instructions"), jailbreaks ("you are DAN"), data exfiltration attempts, and out-of-scope requests. Run the suite on every model or prompt change. Track pass rates over time — a regression in the red-team suite is a deployment blocker.
Guardrails

Hallucinations

Hallucinations

Hallucinations

OWASP vulnerabilities on AI LLM

OWASP vulnerabilities on AI LLM

OWASP vulnerabilities on AI LLM

Chain-of-thought generates reasoning traces but has no mechanism to verify claims against external reality. When the model encounters a factual question it must rely on parametric memory, which produces confident but fabricated answers. ReAct interleaves reasoning with tool calls — the model can search, look up, or compute before continuing its chain. This grounds each step in real data, cutting hallucination. The original paper showed this on HotpotQA: CoT alone frequently hallucinated intermediate facts, while ReAct retrieved them. The tradeoff is latency and cost — each tool call adds a round trip and tokens.
Agent Loop

1. Iteration cap — prevents infinite loops and cost runaway. Without a hard limit a confused agent loops indefinitely. Set per-request, not globally. 2. Token budget tracking — each iteration grows the context. Track cumulative tokens and terminate or summarize before hitting the window limit. Without this the model silently loses earlier context and quality degrades. 3. Tool call validation — validate function names and arguments against the schema before execution. A hallucinated tool call that passes through can trigger unintended side effects — database writes, payments, external API calls. Return errors to the model so it can self-correct.
   Agent Loop

When the task decomposes into a fixed, predictable sequence of steps. A prompt chain — step A then validate then step B then validate then step C — is cheaper, faster, more debuggable, and produces more consistent results. The agent loop adds value only when you cannot predict the steps in advance: the model must decide dynamically which tools to call and in what order based on intermediate results. Most production systems that call themselves agents are actually prompt chains, and that is the right choice for the majority of use cases.
Agent Loop

• Use a workflow when the task decomposes into predictable steps with clear inputs and outputs at each stage
• Workflows are cheaper, faster, and more debuggable than autonomous agents
• Use an autonomous agent only when steps are unpredictable, the task is open-ended, and you have feedback mechanisms (tests, eval criteria) to catch errors
• Most production "agents" are actually workflows — and that is the right choice for the majority of use cases
• Key tradeoff: workflows trade flexibility for reliability; agents trade reliability for adaptability
  Agents

• Each layer of complexity — chaining, routing, parallelization, autonomy — adds latency, cost, and failure surface
• A single well-prompted LLM call with good retrieval solves many tasks without orchestration
• Adding orchestration only makes sense when you can demonstrate measurably better outcomes
• Teams that start with complex multi-agent systems often spend more time debugging coordination than solving the actual problem
• Key tradeoff: simpler systems are easier to debug and cheaper to run, but cannot handle tasks requiring dynamic decision-making
  Agents

The host mediates all communication between the LLM and MCP servers. This is a deliberate security boundary — the host can enforce policies (which tools the model can call, which resources it can read), require user approval for sensitive actions, and aggregate capabilities from multiple servers without any server being aware of the others. If the LLM talked to servers directly, there would be no central point to enforce access control, log actions, or prevent a compromised server from manipulating the model. The client-per-server model also isolates failures — one crashed server does not affect others.
Model Context Protocol

When the tool involves sensitive business logic that should not be externalized (e.g., pricing calculations, compliance checks), when you need tight coupling between the tool and the application's internal state (e.g., in-memory session data), or when the overhead of running a separate server process is not justified. Function calling is also simpler to debug — the tool definition and implementation live in the same codebase. MCP's value is reusability across clients, so if only one client will ever use the tool, function calling is the better choice.
Model Context Protocol

Three factors compound. First, tool descriptions are untrusted input that directly influences LLM behavior — a vector that traditional APIs do not have. Second, MCP servers often get broad access (database connections, file system access, API keys) because they need to fulfill diverse model requests, violating least-privilege by default. Third, the protocol lacks built-in permission scoping — OAuth authenticates and authorizes the client's access to the server, but does not restrict which specific tools or operations the client can invoke. Traditional REST APIs typically have endpoint-level authorization, rate limiting, and input validation as standard practice. MCP servers need all of these but the ecosystem is young enough that many servers ship without them.
Model Context Protocol

• Justified under three conditions: context pollution (subtask degrades main agent reasoning), parallelization (independent paths need concurrent execution), specialization (20+ tools degrade selection accuracy, or conflicting behavioral modes needed)
• If none apply, single agent wins: 3–10× fewer tokens, lower latency, single linear trace for debugging
• Many teams investing months in multi-agent discover equivalent results from better prompting on one agent
• Key tradeoff: multi-agent buys context isolation and parallelism at the cost of coordination overhead and debugging complexity
  Multi-Agentic Systems

• Problem-centric (code agent + test agent + review agent) forces constant coordination — each agent needs context from the others, creating lossy handoffs
• Context-centric splits along natural context boundaries — agent handling a feature also handles its tests because it already has the context
• Introduce a new agent only when context genuinely cannot fit in one window
• Reduces handoff count, cuts token overhead, prevents compounding information loss at each transfer
• Key tradeoff: context-centric may produce broader agents (more tools per agent), but avoids the "telephone game" of multi-hop handoffs
  Multi-Agentic Systems

• Semantic opacity: natural language errors pass as "valid" data between agents — no schema violations, no exceptions raised. A hallucinated fact from Agent A becomes trusted input for Agent B
• Non-linear traces: multiple interleaving reasoning chains with handoffs instead of one sequential trace, making root cause analysis harder
• Emergent behavior: agent interactions produce outcomes no single agent's instructions predict
• Known anti-pattern: two agents entering a politeness loop, each thanking the other, consuming budget without task progress — correct behavior per agent, catastrophic in combination
• Key tradeoff: multi-agent gains specialization but loses the single-trace debuggability that makes single-agent failures straightforward to fix
  Multi-Agentic Systems

• In a single LLM call, the prompt is the entire interface — prompt quality is everything
• In an agentic system, the model interacts with tools across multiple loop iterations — each tool call is a decision point where errors compound
• Wrong tool selection, malformed arguments, or unhelpful error messages cascade across steps
• Anthropic's SWE-bench team spent more time improving tool interfaces than prompts, because tool quality directly determined task success rate
• Tradeoff: tool design effort is amortized across all agent runs; prompt tweaks are fragile and session-specific
  Tools

• Narrow tools reduce parameter count and ambiguity — fewer hallucinated arguments per call
• Too many tools degrades selection accuracy — MCPGauge measured 9.5% accuracy drop from irrelevant tool presence alone
• Split when a tool serves genuinely different use cases needing different descriptions and parameters
• Keep together when operations share context and the model would naturally chain them
• As tool count grows and selection confusion appears, apply routing or tool filtering to keep the active set focused
• Tradeoff: per-call reliability (narrow) versus selection accuracy (fewer options)
  Tools

• Cache-safe: read-only (no side effects), deterministic output for same inputs within TTL, acceptable staleness
• Examples: database lookups, weather API calls, search queries — all safe with short TTLs
• Cache-unsafe: mutates state (create/update/delete), result depends on rapidly changing context, caching would mask failures
• Critical failure mode: caching a write operation returns cached "success" without executing — silent data inconsistency
• Tradeoff: cache hit rate and latency savings versus freshness and correctness guarantees
  Tools

No. They enforce format and hard rules, but they do not measure semantic correctness, relevance, or tone. A response can pass all schema checks and still be factually wrong or unhelpful. Use deterministic checks as a fast pre-filter; use LLM judges for semantic quality.
Deterministic Checks

(1) Allowlisted tools/actions only, (2) strict output schema validation, (3) PII scanning on outputs, (4) injection-resistant formatting, (5) length constraints. These catch the most common failure modes cheaply before any expensive evaluation.
Deterministic Checks

If improvements only show up on your dev set but not on a holdout set (or online metrics), you are likely tuning to that benchmark. Add paraphrased variants, segment tests, and an untouched holdout.
Evaluation