ASP.NET Core interview questions covering performance, caching & http.
Open a question for the full answer, code and interview guidance.
Performance affects response time, throughput, infrastructure cost, scalability, and user experience. A well-performing ASP.NET Core application avoids unnecessary blocking, allocations, database round trips, network calls, and repeated computation.
Asynchronous I/O allows a request thread to return to the thread pool while waiting for operations such as database queries, file access, or HTTP calls. This improves scalability when many requests are waiting on external I/O.
Caching stores data or generated results that are expensive to retrieve or compute so later requests can reuse them. It can reduce database load, external API calls, CPU work, and response latency.
IMemoryCache provides an in-process cache stored in the application's memory. It is fast and simple because no network call is required to access cached values.
IDistributedCache is an abstraction for a cache that can be shared by multiple application instances. Implementations can use external distributed storage rather than the memory of one web process.
In-memory caching stores data inside one application process and is usually the fastest option. However, the data disappears when that process stops and is not automatically shared with other instances.
Absolute expiration removes or expires an entry after a fixed time or at a fixed timestamp regardless of how frequently it is accessed.
Cache invalidation is the process of removing or replacing cached data when it is no longer valid. It is one of the most important challenges in cache design.
Output caching stores complete HTTP responses on the server and can serve a cached response for later matching requests without executing the full endpoint again.
Response caching follows HTTP caching semantics and relies heavily on cache-related request and response headers. It is designed around standard HTTP caching behavior.
HTTP caching headers communicate how clients and intermediary caches may store and reuse a response. Cache-Control directives can specify rules such as public, private, no-store, max-age, and revalidation behavior.
Response compression reduces the number of bytes sent over the network for compressible responses such as HTML, JSON, CSS, and JavaScript. Smaller payloads can improve transfer time and reduce bandwidth consumption.
HTTP/2 improves transport efficiency compared with HTTP/1.1 through features including multiplexing multiple request/response streams over one connection and compressed request headers.
HTTP/3 carries HTTP semantics over QUIC rather than TCP. QUIC uses UDP as its transport and integrates modern encryption and stream multiplexing.
Connection pooling reuses expensive connections instead of creating a new physical connection for every operation. Database providers commonly pool database connections, while HttpClient infrastructure pools outgoing network connections through handlers.
IHttpClientFactory centralizes HttpClient configuration and manages underlying HttpMessageHandler lifetimes. It helps avoid common connection-management problems caused by repeatedly constructing and disposing HttpClient handlers.
A named client is configured under a string name and created through IHttpClientFactory. It is useful when several logical clients need different base addresses, headers, or settings.
Database operations are often a major source of application latency. Common problems include retrieving unnecessary columns or rows, missing indexes, N+1 queries, excessive SaveChanges calls, long transactions, and unnecessary change tracking.
Pagination limits the amount of data retrieved, processed, serialized, transferred, and rendered in a single request. Returning thousands of records at once increases database load, memory usage, network traffic, and response time.
Return only the data the client needs. Use DTO projections rather than serializing large entity graphs, paginate collections, avoid unnecessary nested objects, and compress suitable responses.
Rate limiting restricts how frequently clients can access selected endpoints. It can protect application capacity, reduce abuse, and provide fairer resource usage.
Timeouts prevent requests or downstream operations from consuming resources indefinitely. Outgoing HTTP calls, database commands, and long-running application operations should have limits appropriate to their expected duration.
Vertical scaling increases the resources of one application host, such as CPU or memory. It is simple but has hardware limits and can leave one large instance as a significant failure domain.
Measure before optimizing. Use production metrics, distributed traces, structured logs, profilers, database query analysis, and controlled load testing to determine where time and resources are actually being consumed.
Use asynchronous APIs for I/O-bound work, propagate cancellation, keep database queries efficient, paginate large result sets, and return only required data. Reuse outbound HTTP connections through IHttpClientFactory and configure sensible timeouts.