Senior ASP.NET Core Web API interview questions covering API design, architecture, scalability, distributed systems and production scenarios.
Open a question for the full answer, code and interview guidance.
Start with a clear public contract and separate HTTP concerns from application and domain logic. Use request/response DTOs, validation, authentication, policy-based authorization, consistent ProblemDetails errors, asynchronous I/O, cancellation, structured logging, and appropriate persistence boundaries.
Organize around responsibilities and business capabilities rather than allowing controllers, entities, and infrastructure code to become tightly coupled. A common design separates API presentation, application use cases, domain rules, and infrastructure integrations.
Clean Architecture places business rules and use cases toward the center while infrastructure and delivery mechanisms such as ASP.NET Core, EF Core, and external APIs remain at outer boundaries.
CQRS separates command operations that change state from query operations that read state. It can be useful when read and write models have significantly different requirements, workflows are complex, or independent optimization provides value.
First measure the actual bottlenecks. Optimize database queries and indexes, paginate large results, reduce payload size, cache safe hot data, use asynchronous I/O, pool reusable resources, and scale application instances horizontally when appropriate.
Use metrics and distributed traces to determine where request time is spent, then correlate with structured logs. Examine database duration and generated SQL, downstream HTTP calls, serialization cost, thread-pool behavior, resource saturation, locks, and cache effectiveness.
Do not load and return an unbounded table. Apply server-side filtering and pagination with deterministic ordering, return only required fields, and consider keyset pagination for large sequential datasets.
Enforce explicit size limits and validate file type using more than the client-supplied filename or Content-Type alone. Stream large content rather than buffering the entire file in memory, and store it in an appropriate object/file storage system rather than automatically in the web root.
Authorize access to the requested file before returning its contents. Resolve the storage object using a server-controlled identifier rather than accepting arbitrary filesystem paths from the client.
Use an idempotency mechanism for operations that may be retried. The client sends a unique idempotency key, and the server atomically associates that key with the operation and its outcome.
Use optimistic concurrency when multiple clients may edit the same resource. A version token, rowversion, or ETag can represent the state the client originally read.
An ETag is an opaque validator representing a particular version of a resource representation. Clients can use If-None-Match for cache revalidation or If-Match to make updates conditional on a known version.
Place each external integration behind a focused client abstraction and configure it through IHttpClientFactory. Apply explicit timeouts, cancellation, resilience policies, and observability per dependency.
Eventual consistency means different parts of a distributed system may temporarily observe different state, but they converge after asynchronous processing completes. It is common when services own separate databases and communicate through messages or events.
The Outbox pattern helps reliably coordinate a database state change with publication of an integration message. The application writes both the business change and an outbox record in the same local database transaction.
Do not keep a normal HTTP request open for a report that may take minutes. Create a job record, enqueue durable work, return 202 Accepted with a status location, and process the report asynchronously.
Tenant identity should come from a trusted authenticated context or validated routing model, not from an arbitrary client field that is accepted without verification. Every tenant-owned query and mutation must enforce the tenant boundary.
Accept purpose-specific request DTOs containing only fields the client is allowed to control. Map those fields explicitly to domain entities rather than binding persistence entities directly.
Prefer additive changes when they do not alter existing semantics. For incompatible changes, introduce a new contract or version and keep the older contract available during a documented migration period.
Do not leak the downstream provider's internal exception, URL, credentials, or raw body. Translate failures into your API's documented error model based on what the failure means to your client.
Process-local memory caches are independent on each instance, so shared cache requirements generally need a distributed cache or another coordinated mechanism. Define cache keys, tenant/user partitioning, expiration, invalidation, and failure behavior explicitly.
Choose the rate-limit partition using trusted identity information such as an authenticated client, API key, or correctly processed forwarded address. Do not blindly trust arbitrary forwarding headers supplied directly by the internet.
Use structured logs, metrics, and distributed traces together. Track request rate, latency percentiles, errors, saturation, database and external dependency duration, retry/circuit-breaker activity, queue depth, cache effectiveness, and business-critical outcomes.
Start with the deployment time window and compare error rates by endpoint, instance, version, and dependency. Use trace identifiers to connect failed requests to logs and distributed traces, then inspect exceptions, database failures, configuration differences, timeouts, resource pressure, and recent schema changes.
Senior API design balances correctness, security, maintainability, operability, performance, and client compatibility rather than optimizing only controller code. It defines explicit contracts, keeps business logic independent from transport details, uses data access intentionally, and treats authorization and tenant boundaries as server-enforced invariants.