Why should you care?

ShopNest product search under Flipkart traffic must not block threads; async keeps the server responsive during database waits.

See it live — copy this example

Paste into a .NET project with EF Core packages, then run with LocalDB/SQL Server (dotnet ef / dotnet run).

public async Task<Product?> GetProductAsync(int id, CancellationToken ct)
{
    return await _context.Products
        .AsNoTracking()
        .FirstOrDefaultAsync(p => p.Id == id, ct);
}

public async Task<int> SaveOrderAsync(Order order, CancellationToken ct)
{
    await _context.Orders.AddAsync(order, ct);
    return await _context.SaveChangesAsync(ct);
}

What happened?

• FirstOrDefaultAsync yields during network I/O.
• CancellationToken propagates request abort.
• AddAsync and SaveChangesAsync have async counterparts throughout EF Core.

Practice next

1. Convert one sync ToList to ToListAsync in an API endpoint.
2. Pass CancellationToken from controller through service to EF calls.
3. Avoid .Result or .Wait() on async EF calls — causes deadlocks.
4. Add ct.ThrowIfCancellationRequested() before heavy queries in long reports.
5. Benchmark sync vs async under load test — async wins on concurrent reads.

Remember

Async EF methods improve scalability under I/O wait. Use Async suffix methods consistently. Thread CancellationToken through the stack.

ShopNest peak traffic

Product API uses ToListAsync with CancellationToken during sale hour traffic spike.

Outcome: Server handles more concurrent shoppers without thread pool starvation.