Category: System design

A few days ago, I came across a post explaining async and await in C#. It talked about state machines, ThreadPool, asynchronous operations, and methods resuming after await.

I read the entire post.

Honestly…

I understood almost nothing.

Like many developers, I had a few assumptions in my head:

• Does async create a new thread?
• Does await stop the thread?
• If the method pauses, what exactly is paused?
• When execution resumes, why doesn’t it immediately execute the next line?
• If another thread continues the work, how does the program know where to continue?

The more I thought about it, the more confused I became.

So I started asking questions.

The first realization completely changed my understanding:

async does not create a new thread.

That surprised me.

For years, I subconsciously associated async with “background thread.”

It isn’t.

async simply tells the compiler that the method contains asynchronous operations and can be paused and resumed.

Then came the second realization:

await pauses the method, not the thread.

That sentence looks simple, but it took me a while to truly understand it.

Imagine an ASP.NET Core API.

A request arrives, and a ThreadPool thread starts executing your controller action.

Eventually, the code reaches this line:

await _repository.GetCustomerAsync();

The database now needs a few seconds to respond.

My original assumption was that the thread would just sit there waiting.

Wrong.

The thread is released back to the ThreadPool so it can serve another request.

Your method remembers exactly where it stopped.

When the database finishes, .NET picks an available thread and continues executing the method from the line after await.

Another question immediately came to my mind.

“If execution continues after await, shouldn’t the next line execute immediately?”

Then I realized something I had completely overlooked.

Consider this example:

public async Task SaveCustomerAsync()
{
    Console.WriteLine("Step 1");

    await SaveToDatabaseAsync();

    Console.WriteLine("Step 2");
}

public async Task SaveToDatabaseAsync()
{
    await Task.Delay(5000);

    Console.WriteLine("Database Saved");
}

Initially, I expected the output to be:

Step 1
Step 2
Database Saved

But that’s not what happens.

The actual output is:

Step 1
Database Saved
Step 2

Why?

Because SaveCustomerAsync() isn’t waiting for Task.Delay().

It’s waiting for the entire SaveToDatabaseAsync() method to finish.

Only after that method completes does execution continue after its own await.

That was my “aha!” moment.

Finally, I understood the role of threads.

Threads don’t travel with your method.

They simply execute whatever work is ready.

When an await is reached:

• The method pauses.
• The current thread is released.
• The asynchronous operation continues elsewhere (such as the database or operating system).
• When the operation finishes, an available ThreadPool thread resumes the method.

No thread sits idle.

No CPU cycles are wasted waiting.

That’s why async/await improves the scalability of applications like ASP.NET Core APIs.

Looking back, I realized something important.

Understanding async/await isn’t about memorizing definitions.

It’s about asking the right questions.

Sometimes the biggest breakthrough comes from admitting:

“I don’t actually understand this yet.”

And that’s perfectly okay.

Every experienced developer has been there.

If this post clears up the same confusion I had, then sharing my learning journey was worth it.