
Async vs Sync in .NET: Understanding ThreadPool Impact | Stefan Đokić posted on the topic | LinkedIn
Some developers still think async/await makes code faster. I thought the same when I started with .NET. Then one day, our API started slowing down under load. Not because of the CPU. Not because of the database. Because we were blocking threads everywhere. .Result .Wait() Sync database calls Sync HTTP calls Everything worked perfectly… until traffic increased. What many developers miss is this: Async doesn’t make one request faster. A request that takes 400ms with sync code will still take ~400ms with async. The real difference is what happens to the ThreadPool. With synchronous code: Thread → waits for HTTP → waits for DB → waits for I/O The thread is blocked the whole time. With async code: Thread → starts I/O → returns to ThreadPool OS notifies completion → continuation resumes. That single difference is what allows ASP .NET Core to handle thousands more concurrent requests. The real killer I keep seeing in production codebases is this: Sync-over-async var result = httpClient.SendAsync(...).Result; This blocks the thread again and under load it can lead to ThreadPool starvation. And once that happens, your API starts feeling “mysteriously slow”. No CPU spikes. No database bottlenecks. Just no threads left to process requests. I made this visual to explain what actually happens inside ASP .NET Core. Curious: Have you ever debugged a production issue that turned out to be sync-over-async? __ 📌 Don't miss the next newsletter issue, 20,000 engineers will read it, join them: thecodeman.net 📌 Join our Free Closed .NET Hub (1.1k members) and get access to content nobody publicly has: https://lnkd.in/gu_5HiMD ♻️ Repost to others. 📂 You can save this post for later, and you should do it. ➕ Follow me ( Stefan Đokić ) to learn .NET and Architecture every day. | 32 comments on LinkedIn





💕