Q1. Your ASP.NET Core Web API is slow in production. How would you investigate and improve its performance?
Investigation
Start with observability:
Application Insights
OpenTelemetry
Serilog
dotnet-counters
dotnet-trace
Measure:
Request latency
SQL execution time
ThreadPool usage
Memory consumption
GC activity
External API response times
Common Bottlenecks
Slow SQL Queries
N+1 Queries
Blocking Calls (.Result/.Wait())
Large Payloads
ThreadPool Starvation
Excessive Logging
Improvements
✅ Use async/await
✅ Add database indexes
✅ Cache frequently accessed data
✅ Use pagination
✅ Response compression
✅ Optimize EF Core queries
✅ Use CDN for static files
✅ Reduce serialization overhead
Example
var customers = await _dbContext.Customers
.AsNoTracking()
.ToListAsync();Q2. Your application needs to call an external API that sometimes fails or responds slowly. How would you make the integration resilient?
Use resilience patterns.
Retry
builder.Services.AddHttpClient("Orders")
.AddPolicyHandler(
Policy.Handle<HttpRequestException>()
.WaitAndRetryAsync(3,
retry => TimeSpan.FromSeconds(
Math.Pow(2, retry))));Additional Patterns
✅ Retry
✅ Circuit Breaker
✅ Timeout
✅ Bulkhead Isolation
✅ Fallback
Example Flow
API Fails
↓
Retry
↓
Still Fails
↓
Circuit Opens
↓
Fallback Response
Q3. Users occasionally submit the same payment request multiple times. How would you prevent duplicate processing?
Implement Idempotency.
Example
POST /payment
Idempotency-Key: ABC123
Store the key.
Request Received
↓
Has Key Been Processed?
↓
Yes → Return Existing Result
No → Process Payment
Database table:
IdempotencyKey
RequestId
Response
This prevents duplicate charges.
Q4. A background task takes several minutes to complete and should not block the API response. How would you design it in .NET?
API
[HttpPost]
public IActionResult GenerateReport()
{
_backgroundQueue.QueueJob(...);
return Accepted();
}Response:
202 Accepted
Background Processing
Use:
BackgroundService
IHostedService
Azure Service Bus
RabbitMQ
Hangfire
Architecture:
API
↓
Queue
↓
Background Worker
↓
Process Job
Q5. Your application is consuming too much memory in production. How would you identify and fix the issue?
Investigation
Tools:
dotnet-gcdump
dotnet-dump
Visual Studio Profiler
Application Insights
Check:
✅ Large object allocations
✅ Memory leaks
✅ Static collections
✅ Cache growth

Join the conversation! Your thoughts help the community grow.