Rule of thumb

If your action waits on something external, make it async. If it’s instant CPU, keep it sync; for expensive CPU, offload.

The core idea

• Async shines for I/O-bound work (DB calls, HTTP calls, queues, files). It frees the request thread while waiting, so the server can serve more requests with the same thread pool.
• Sync is fine for trivial, short CPU work (formatting, small calculations) where you’re not awaiting anything and the handler returns in a few milliseconds.

When to choose async

• You call EF Core (SaveChangesAsync, ToListAsync), HttpClient, Azure SDK (ServiceBusClient, BlobClient), file I/O, or any API with Async methods.
• You expect latency from a dependency (tens–hundreds of ms).
• You need cancellation and timeouts (propagate HttpContext.RequestAborted).

When sync is acceptable

• The action is pure CPU and trivial (e.g., quick math, mapping, input validation) and returns immediately.
• There are no I/O waits and no benefit from freeing the thread.

If it’s CPU-heavy (image processing, big JSON transforms), do not just make it async—offload to a background queue/worker or a separate compute service. Async won’t make CPU faster.

Pitfalls to avoid

• Don’t block async: never use .Result / .Wait() on Tasks (deadlocks/thread-pool starvation).
• Async all the way down: if the controller is async, downstream calls should be too.
• Don’t fake async: returning Task.Run around synchronous I/O just burns threads.
• Keep concurrency bounded when fanning out to multiple I/O calls.

Mini decision checklist

1. Any I/O? → Use async (end-to-end).
2. Pure CPU?

• Tiny (≤ a few ms) → Sync is fine.
• Heavy/variable → Offload to background worker; controller returns 202/Location or uses a queue.

ASP.NET Core examples

Async (I/O-bound) — recommended

[ApiController]
[Route("orders")]
public class OrdersController : ControllerBase
{
    private readonly OrdersDbContext _db;
    private readonly HttpClient _http;

    public OrdersController(OrdersDbContext db, IHttpClientFactory f)
    {
        _db = db;
        _http = f.CreateClient("catalog");
    }

    [HttpGet("{id}")]
    public async Task<ActionResult<OrderDto>> Get(string id, CancellationToken ct)
    {
        var order = await _db.Orders.FindAsync([id], ct);
        if (order is null) return NotFound();

        // Call another service
        var resp = await _http.GetAsync($"/inventory/{order.Sku}", ct);
        resp.EnsureSuccessStatusCode();
        var inv = await resp.Content.ReadFromJsonAsync<InventoryDto>(cancellationToken: ct);

        return Ok(new OrderDto(order, inv));
    }
}

Sync (trivial CPU) — acceptable

[HttpGet("ping")]
public ActionResult<string> Ping() => "pong"; // no I/O, returns immediately

CPU-heavy work — offload rather than “asyncifying”

// Controller: accept request, enqueue, return 202
[HttpPost("render")]
public async Task<IActionResult> Render(RenderRequest req, [FromServices] IBackgroundQueue queue)
{
    var jobId = Guid.NewGuid().ToString("N");
    await queue.EnqueueAsync(jobId, req);
    return Accepted($"/render/{jobId}");
}

// Hosted service: single place that uses CPU, bounded concurrency
public class RenderWorker : BackgroundService
{
    private readonly IBackgroundQueue _q;
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        await foreach (var job in _q.DequeueAllAsync(stoppingToken))
        {
            // CPU-bound work here (e.g., image/video), controlled degree of parallelism
        }
    }
}

Tuning & tips

• Pass CancellationToken from HttpContext.RequestAborted.
• Use IHttpClientFactory and async Azure SDKs.
• For streaming, expose IAsyncEnumerable<T> or chunked responses (async).
• In ASP.NET Core there’s no UI SynchronizationContext, so ConfigureAwait(false) is usually unnecessary.