How does async/await work, and why use it in a web API?

Say it out loud, then check

One request through every idea

async, the Task, await, the state machine, the thread going back to the pool, another thread carrying on, and the CancellationToken, in the order they happen for one GET /api/loans/{id}.

The story

1. Before

   Before async, a web API called the database the plain way: db.Loans.FirstOrDefault(...), the non-async twin of FirstOrDefaultAsync. The thread running the request sent the query, then sat and waited for the answer, doing nothing.

   Request A

   Thread pool2 threads

   T1waiting on SQL

   T2free

   Databaseanswers in 300 ms

   1/8Before async: Request A runs on T1, and T1 waits while the database works.Request B takes T2 and waits too. Both threads are doing nothing but waiting.Request C arrives. No free thread, so C waits in a queue, while the CPU sits idle.On the 1st of the month, hundreds arrive. The pool adds threads slowly, so the queue keeps growing.Requests time out. More threads is not the fix. Not holding a thread while waiting is.With await, T1 sends the query and goes straight back to the pool.Free threads drain the queue. When an answer comes back, any free thread finishes that request.Same two threads, no queue. The waiting happens in the database, not on a thread.

   BackPlayNext
2. Why it had to change

   Under load every thread was stuck waiting on I/O (input and output: the database, another API, a file). New requests queued, and the server timed out with the CPU almost idle. That is thread-pool starvation.

3. How it works now

   Put await on the slow call. If the answer isn't there yet, the method pauses and hands its thread back. When the answer arrives, a pool thread carries on from the same line.

4. What happens next

   The compiler writes the hard part for you: it turns the method into a small state machine that remembers which await it reached and the values of its local variables. EF Core and HttpClient give you methods ending in Async that return a Task.

5. What we gained

   Far more requests per server with the same threads, fewer instances to pay for, and no timeouts at month-end peaks. One request is not faster; the server handles more of them at once.

In the lending API

The controller that serves GET /api/loans/{id}. The three marked lines are what makes it async.

Only the key lines are shown; Deep walks the whole file.

The code, file by file

One GET request in the lending API, file by file: controller, service, repository. Every layer returns a Task and awaits the next one. Press Next line to follow Request A through the diagram.

What they ask next

The follow-ups interviews really ask. Answer out loud, then tap to check.

• ReportedDoes async make a request faster?

  No. One request takes about as long, a tiny bit longer because of the state machine. The win is scalability: while it waits, its thread serves other requests, so one server handles many more requests at once.

  Next questions, in Deep →Where this was reported
• ReportedWalk me through what happens when the code hits await.

  The method runs normally until the first await. EF Core hands back an unfinished Task. The compiler-built state machine saves its state number and local variables, and the method returns that unfinished Task to its caller, which does the same. The thread goes back to the pool. When the query finishes, the rest of the method goes into the thread pool's queue of work, and a free thread resumes it at the saved state. The storyboard in Deep shows that whole flow in one request.

  Next questions, in Deep →Where this was reported
• ReportedWhy is .Result or .Wait() dangerous?

  They block the calling thread until the Task finishes, which undoes the whole point of async. In ASP.NET Core, under load, every pool thread ends up blocked and new requests queue: thread-pool starvation. In apps that have a SynchronizationContext, like old ASP.NET or a desktop app, it can also deadlock.

  Next questions, in Deep →Walk the broken and fixed code →Where this was reported

Follow-up tree

Answer, then open the next level. That is the order an interviewer digs in.

Reporteda candidate was asked Intervieweran interviewer asks it

• ReportedDoes async make a request faster?

  No. One request takes about as long, a tiny bit longer because of the state machine. The win is scalability: while it waits, its thread serves other requests, so one server handles many more requests at once.

  Where this was reported
  • When would you not use async?

    For CPU-bound work, like building a 60-month repayment schedule in memory. There is nothing to wait for, so there is nothing to free. Wrapping it in Task.Run in a web API only moves the work to another pool thread and adds overhead. Async is for I/O: databases, HTTP calls, files, queues.

• ReportedWalk me through what happens when the code hits await.

  The method runs normally until the first await. EF Core hands back an unfinished Task. The compiler-built state machine saves its state number and local variables, and the method returns that unfinished Task to its caller, which does the same. The thread goes back to the pool. When the query finishes, the rest of the method goes into the thread pool's queue of work, and a free thread resumes it at the saved state. The storyboard in Deep shows that whole flow in one request.

  Where this was reported
  • What does the state machine look like?

    Roughly this, simplified from what the compiler writes for LoanService.GetAsync. The locals became fields, so they survive the pause. MoveNext runs first on T1. If the Task isn't finished, it sets state 1 and returns, freeing T1. When the Task completes, the pool calls MoveNext again, on T2, and this time it skips straight to the part after the await. You never write this; you only need to know it exists.

    // compiler-written, simplified
    // state, awaiter, loan: fields now;
    // so are id, ct and repo
    void MoveNext()
    {
      if (state == 0)
      {
      awaiter = repo.GetAsync(id, ct)
        .GetAwaiter();
      if (!awaiter.IsCompleted)
      {
        state = 1;
        // when done, call MoveNext again
        awaiter.OnCompleted(MoveNext);
        return; // T1 freed
      }
      }
      // state 1: called again, on T2
      loan = awaiter.GetResult();
      SetResult(LoanResponse.From(loan));
    }

  • Does the method continue on the same thread?

    In ASP.NET Core, usually not. There is no SynchronizationContext, so any free pool thread runs the rest. That is fine: your local variables come back with it, and HttpContext is still the same request. Don't store anything per-thread with ThreadStatic; AsyncLocal flows with the async code instead.

• ReportedWhy is .Result or .Wait() dangerous?

  They block the calling thread until the Task finishes, which undoes the whole point of async. In ASP.NET Core, under load, every pool thread ends up blocked and new requests queue: thread-pool starvation. In apps that have a SynchronizationContext, like old ASP.NET or a desktop app, it can also deadlock.

  Walk the broken and fixed code →Where this was reported
  • ReportedWhat does ConfigureAwait(false) do, and when does .Result deadlock?

    Short version: in old ASP.NET and desktop apps, the code after an await must come back to the one thread that .Result is blocking, so both wait forever. ConfigureAwait(false) says "any thread will do", which matters in shared libraries. ASP.NET Core has no SynchronizationContext, so there it starves instead of deadlocking. The full answer is its own card: ConfigureAwait and deadlocks.

    Asked as "What does ConfigureAwait(false) do" in the question index
  • The interface I implement is synchronous. What then?

    Change the interface to return a Task, and fix the callers. That is the real fix. If it is a framework interface you can't change, look for its async version (most have one, like IAsyncDisposable). Blocking with .GetAwaiter().GetResult() is still blocking; it only gives a cleaner exception.

• Where does the CancellationToken come from in a controller, and what happens if you don't pass it?

  Add a CancellationToken parameter to the action and ASP.NET Core fills it with HttpContext.RequestAborted, which fires when the client disconnects. Pass it to every EF Core and HttpClient call. If you don't, a customer who closes the page leaves a 20-second report query running on SQL for nothing. When it fires, the call throws OperationCanceledException; keep that out of your error alerts, since the client is already gone.

  public async Task<IActionResult> Statement(
    Guid id, CancellationToken ct)
  {
    var rows = await db.Payments
      .Where(p => p.LoanId == id)
      .ToListAsync(ct);
    return Ok(rows);
  }

• What is the difference between a Task and a Thread?

  A thread is a worker that runs code. A Task is a promise of a result. For I/O, a Task uses no thread while it waits. See Task and the full card Task vs Thread.

• How do you call two services at the same time?

  Start both calls, then await Task.WhenAll(...), so the total time is the slower call, not the sum. Never do this with two queries on the same DbContext: it handles one operation at a time and throws (see the parallel bug on the lifetimes card).

  Task<Score> score =
    bureau.GetScoreAsync(id, ct);
  Task<KycResult> kyc =
    kycClient.CheckAsync(id, ct);
  await Task.WhenAll(score, kyc);

• How would you find sync-over-async in production? How did you measure it?

  Three signals together: latency up while CPU stays low; dotnet-counters showing the thread pool thread count climbing one or two a second with a long queue; and App Insights showing requests slow while their SQL and HTTP dependencies are fast. Then dotnet-stack on one instance shows many threads stuck in Task.Result. To stop the next one, the analyzer rule VSTHRD002 ("avoid synchronous waits") fails the build.

• Is async void ever OK?

  Only for event handlers in desktop apps, where the signature must be void. In a web API, never: its exception can't be caught by the caller and crashes the process.

  See the async void crash →

Production bugs, and how to tell them

Each one: what you see, why, the fix in code, and the line to say.

• Sync over async: .Result starves the thread pool

  No exception. Under load: requests take 30 s, the gateway returns 504, CPU sits at 15%, and the credit bureau answers in 800 ms.
  $ dotnet-counters monitor -n Lending.Api
    ThreadPool Queue Length     412
    ThreadPool Thread Count      58  (climbing ~1/s)

  Cause

  CreditCheckService.Check was synchronous, so it called the async bureau client and blocked on it with .Result. Each request held its thread for the whole bureau call.

  Fix

  Make the method async and await the call, then make every caller up to the controller async too. Pass the CancellationToken down.

  BeforeAfter

  1public sealed class CreditCheckService(2 ICreditBureauClient bureau)3{4 public CreditResult Check(5 Guid applicantId)6 {7 Score score = bureau8 .GetScoreAsync(applicantId)9 .Result;10 return CreditResult.From(score);11 }12}

  Before · CreditCheckService.cs · line 2 · 1 of 4Built by the container. ICreditBureauClient is a typed HttpClient: a class that wraps an HttpClient for one API, registered with AddHttpClient.

  BackNext line

  Say it

  We had a synchronous service calling an async HTTP client with .Result. Each request held a pool thread for the whole bureau call, so under load the pool ran dry and the queue grew while the CPU sat idle. I made the chain async from the controller down and passed the token through, and we turned on the analyzer rule that flags blocking waits.

• async void: one failed SMS crashes the whole API

  Unhandled exception. System.Net.Http.HttpRequestException: Connection refused (sms-gateway:443)
     at Lending.Api.Notifications.WelcomeSms.Send(Loan loan)
     at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__128_1(Object state)
     at System.Threading.ThreadPoolWorkQueue.Dispatch()
  (process exits; App Service restarts it; every in-flight request fails)

  Cause

  WelcomeSms.Send was async void, so it returned no Task. When it failed after its await, .NET had nowhere to deliver the exception, so it threw it again on a thread-pool thread with nothing around it to catch it. An uncaught exception on any thread ends the process.

  Fix

  Return a Task and await it inside a try and catch block, so a failed SMS is logged and the loan is still created. Better still, put the SMS on a queue for a background worker.

  BeforeAfter

  1public sealed class WelcomeSms(2 ISmsGateway sms)3{4 public async void Send(Loan loan)5 {6 await sms.SendAsync(loan.Phone,7 "Welcome to BMW Financial");8 }9}10 11// LoansController.CreateAsync, the caller:12welcome.Send(loan); // can't be awaited

  Before · WelcomeSms.cs · line 2 · 1 of 5Built by the container. ISmsGateway wraps the SMS provider's HTTP API.

  BackNext line

  Say it

  A welcome SMS method was async void. When the SMS gateway was down, its exception had no Task to go to, so it crashed the process and took every in-flight request with it. I changed it to return a Task and awaited it in a try/catch; later we moved it to a queue so the request doesn't wait on SMS at all.

• Forgot await: "Cannot access a disposed context"

  System.ObjectDisposedException: Cannot access a disposed context instance. A common cause of this error is disposing a context instance that was resolved from dependency injection and then later trying to use the same context instance elsewhere in your application.
  Object name: 'ServicingDbContext'.
  (build warning ignored: CS4014 Because this call is not awaited, execution of the current method continues before the call is completed)

  Cause

  The controller called audit.WriteAsync(...) without await. The response went out, the request's scope disposed the DbContext, and then the audit code tried to save with it.

  Fix

  await the call, so the request (and its DbContext) stays alive until the audit row is saved. Treat warning CS4014 as an error.

  BeforeAfter

  Diagram · step 1A POST arrives. The request's scope holds the controller and its DbContext.Show diagram

  Request scopeone per request

  CreateAsync

  DbContext

  1[HttpPost]2public async Task<IActionResult> CreateAsync(3 CreateLoanRequest req, CancellationToken ct)4{5 Loan loan =6 await loans.CreateAsync(req, ct);7 audit.WriteAsync(loan.Id); // no await8 return CreatedAtAction(9 nameof(GetAsync), new { loan.Id }, loan);10}11 12// AuditWriter.WriteAsync, still running:13await db.SaveChangesAsync();

  Before · LoansController.cs · line 2 · 1 of 4Runs inside the request's scope, which holds this request's ServicingDbContext. loans and audit (an AuditWriter) came in through the controller's constructor; the container gave AuditWriter the same request's ServicingDbContext.

  BackNext line

  Say it

  Someone dropped an await on an audit write, so the request finished and its DbContext was disposed while the audit was still running. Some audit rows never saved. We awaited it and made the not-awaited warning a build error.

Traps

• Don't sayasync runs my method on a new thread.Sayasync creates no thread. While the method waits on I/O, no thread is used at all.
• Don't sayawait blocks until the result comes back.Sayawait pauses the method, not the thread. The thread goes back to the pool and serves other requests.
• Don't sayAsync makes each request faster.SayIt lets the server handle more requests at once. A single request is about the same speed.
• Don't sayI'll wrap it in Task.Run to make it async.SayIn a web API, Task.Run just borrows another pool thread. Use the real async API, like ToListAsync.
• Don't sayI'd spot blocking calls in code review.SayI'd measure: dotnet-counters thread count and queue length, plus App Insights request time against dependency time.

Traps

What should you say instead? Tap to check.

• Don't sayasync runs my method on a new thread.

  Say instead

  async creates no thread. While the method waits on I/O, no thread is used at all.

• Don't sayawait blocks until the result comes back.

  Say instead

  await pauses the method, not the thread. The thread goes back to the pool and serves other requests.

• Don't sayAsync makes each request faster.

  Say instead

  It lets the server handle more requests at once. A single request is about the same speed.

• Don't sayI'll wrap it in Task.Run to make it async.

  Say instead

  In a web API, Task.Run just borrows another pool thread. Use the real async API, like ToListAsync.

• Don't sayI'd spot blocking calls in code review.

  Say instead

  I'd measure: dotnet-counters thread count and queue length, plus App Insights request time against dependency time.