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

Say it out loud, then check

Inside the compiler: the async state machine

When you write async and await, the C# compiler transforms your method into a state machine struct implementing IAsyncStateMachine.

The story

1. Before

   In synchronous code, a thread pool worker thread is assigned to the request when it enters Kestrel (ASP.NET Core's web server). When that thread calls a database query or an external credit bureau API, it sits blocked doing nothing until the network packets return. That thread cannot do any other work.

2. Why it had to change

   Under heavy traffic, hundreds of requests hit blocking I/O simultaneously. The thread pool runs out of available threads, known as thread-pool starvation. New requests pile up in the thread pool queue, and latency surges across the entire server, even on simple in-memory endpoints.

3. How it works now

   With async and await, the method is split at the suspension point. When your code awaits an incomplete Task, the calling thread is returned directly to the thread pool to process other incoming traffic. No thread is held while waiting for network or disk I/O.

4. What happens next

   When the database driver receives the response packets from the socket, the operating system notifies the .NET runtime. The runtime queues a continuation (the callback that executes the remaining code) to the thread pool, and any available worker thread picks up execution right after the await statement.

5. What we gained

   Server throughput (the number of concurrent requests served per second) multiplies by orders of magnitude. A small pool of 10 to 20 threads can easily handle 5,000 concurrent I/O-bound requests without exhausting server memory or stalling response times.

In the lending API

The lines that matter.

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

The code, file by file

In ASP.NET Core, routing directs an incoming HTTP request to LoansController.GetByIdAsync, injecting services from DI (ILoanService, ILoanRepository, ServicingDbContext). Stepping through shows the execution flow down the call stack and back up.

What they ask next

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

• What does ConfigureAwait(false) do, and do we need it in ASP.NET Core?

  In UI apps or legacy ASP.NET with a SynchronizationContext, ConfigureAwait(false) tells the runtime not to marshal the continuation back onto the original context. In ASP.NET Core, there is no SynchronizationContext, so continuations always resume on an arbitrary thread pool thread. Thus, ConfigureAwait(false) is not required in application code, though it remains best practice in shared libraries.

  Next questions, in Deep →
• What is the difference between Task and ValueTask, and when would you choose ValueTask?

  Non-cached Task instances allocate a reference object on the heap, whereas Task.CompletedTask is reused for synchronous non-generic tasks. ValueTask is a discriminated union value type that allocates zero heap memory when the operation completes synchronously (such as from a cache or buffer). Choose ValueTask only on hot paths where synchronous completion occurs the vast majority of the time, and remember that a ValueTask can only be awaited once.

  Next questions, in Deep →

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

• What does ConfigureAwait(false) do, and do we need it in ASP.NET Core?

  In UI apps or legacy ASP.NET with a SynchronizationContext, ConfigureAwait(false) tells the runtime not to marshal the continuation back onto the original context. In ASP.NET Core, there is no SynchronizationContext, so continuations always resume on an arbitrary thread pool thread. Thus, ConfigureAwait(false) is not required in application code, though it remains best practice in shared libraries.

• What is the difference between Task and ValueTask, and when would you choose ValueTask?

  Non-cached Task instances allocate a reference object on the heap, whereas Task.CompletedTask is reused for synchronous non-generic tasks. ValueTask is a discriminated union value type that allocates zero heap memory when the operation completes synchronously (such as from a cache or buffer). Choose ValueTask only on hot paths where synchronous completion occurs the vast majority of the time, and remember that a ValueTask can only be awaited once.

• How does exception handling differ between await, .Result, and Task.Wait()?

  await unwraps the exception and throws the original exception directly (e.g., InvalidOperationException), preserving the original stack trace. In contrast, .Result and Task.Wait() wrap all exceptions in an AggregateException. Note that when awaiting a composite task like Task.WhenAll, await unrolls only the first exception, whereas inspecting task.Exception reveals all faulted exceptions.

• What happens if a client disconnects mid-request, and how should your async code handle it?

  When a client disconnects, Kestrel cancels HttpContext.RequestAborted. By passing CancellationToken down to EF Core, HttpClient, and external service calls, the runtime aborts running database queries and socket reads immediately, throwing OperationCanceledException and freeing server resources instead of doing wasted work.

Production bugs, and how to tell them

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

• Thread-pool starvation via sync-over-async (.Result)

  Server response p95 jumped to 14 seconds across all endpoints; CPU sat at 30%.

  Cause

  Calling .Result or .Wait() on an incomplete Task blocks the calling ThreadPool thread for seconds. Under burst traffic, all threads are blocked waiting, causing thread-pool starvation as the pool throttles thread injection to 1-2 per second.

  Fix

  Replace .Result with await, make the method signature async Task, and pass CancellationToken throughout.

  Lending.sln · where these 2 files sit

  • src/Services/
    • DocService.old.cs
    • DocService.cs

  BeforeAfter

  1public byte[] GetPdf(LoanContract contract)2{3 // BLOCKS ThreadPool thread for seconds!4 return _docClient5 .RenderAsync(contract)6 .Result;7}

  BackNext file

  Say it

  "A helper called an external API using .Result, blocking ThreadPool threads for seconds. At 40 concurrent requests the pool starved. We made it async end to end with await and enabled Roslyn analyzer VSTHRD002 to ban .Result in CI."

• Process crash from unhandled exception in async void

  Application suddenly crashed and restarted; event log showed unhandled exception.

  Cause

  An asynchronous background notification method was declared as async void instead of async Task. When the email service threw a network exception, the caller had no Task to await, so the exception bypassed the try/catch block and crashed the process via the unhandled exception handler.

  Fix

  Change method return type from void to Task so the caller can await it and catch exceptions cleanly.

  Lending.sln · where these 2 files sit

  • src/Notifications/
    • EmailSender.old.cs
    • EmailSender.cs

  BeforeAfter

  1// DANGEROUS: exceptions crash the process!2public async void SendNotice(string email)3{4 await _client.SendEmailAsync(email);5}

  BackNext file

  Say it

  "An async void method threw an exception that escaped try/catch and brought down the API. In ASP.NET Core, async void is banned because unhandled exceptions terminate the process; methods must always return Task or Task<T>."

• ObjectDisposedException from returning Task inside using

  System.ObjectDisposedException: Cannot access a disposed context.

  Cause

  A developer elided await to optimize away the state machine while querying inside a using block. The method returned the pending Task and immediately disposed the DbContext before the database query finished executing.

  Fix

  Add await inside the method so the resource remains alive until the asynchronous operation finishes.

  Lending.sln · where these 2 files sit

  • src/Data/
    • LoanQuery.old.cs
    • LoanQuery.cs

  BeforeAfter

  1public Task<Loan?> GetLoan(Guid id)2{3 using var db = _factory.CreateContext();4 // Context disposed before read finishes!5 return db.Loans6 .FirstOrDefaultAsync(l => l.Id == id);7}

  BackNext file

  Say it

  "A method returned a Task directly inside a using block without awaiting it. The using block disposed the DbContext while the query was still in flight, throwing ObjectDisposedException. When disposing resources, you must await before exiting the block."

Traps

• Don't sayAsync and await make my database queries run faster.SayAsync does not reduce query execution time; it releases the server thread while waiting, allowing the web API to handle many more concurrent users.
• Don't sayWrap synchronous database queries in Task.Run inside an ASP.NET Core controller.SayTask.Run borrows a thread-pool thread to block on another thread, burning extra context switches; real async I/O uses non-blocking asynchronous drivers with zero threads.
• Don't sayAlways add ConfigureAwait(false) in ASP.NET Core controllers.SayASP.NET Core has no SynchronizationContext, so ConfigureAwait(false) is redundant in controller actions; it is only necessary in reusable class libraries.
• Don't sayAlways replace Task with ValueTask for performance.SayValueTask is a struct optimization for methods that complete synchronously most of the time; on asynchronous paths it has slightly more overhead, and awaiting it multiple times causes bugs.

Traps

What should you say instead? Tap to check.

• Don't sayAsync and await make my database queries run faster.

  Say instead

  Async does not reduce query execution time; it releases the server thread while waiting, allowing the web API to handle many more concurrent users.

• Don't sayWrap synchronous database queries in Task.Run inside an ASP.NET Core controller.

  Say instead

  Task.Run borrows a thread-pool thread to block on another thread, burning extra context switches; real async I/O uses non-blocking asynchronous drivers with zero threads.

• Don't sayAlways add ConfigureAwait(false) in ASP.NET Core controllers.

  Say instead

  ASP.NET Core has no SynchronizationContext, so ConfigureAwait(false) is redundant in controller actions; it is only necessary in reusable class libraries.

• Don't sayAlways replace Task with ValueTask for performance.

  Say instead

  ValueTask is a struct optimization for methods that complete synchronously most of the time; on asynchronous paths it has slightly more overhead, and awaiting it multiple times causes bugs.