Yes, these are not the same terms, and I would say they are quite different in modern software architecture. It’s very frequent to see asynchronous and non-blocking terms are used interchangeably. Especially, when creating a thread to do some background task and letting the calling thread to continue without waiting for the new asynchronous thread.
But non-blocking now has a very deep meaning, better be said as “how much blocking our applications are”.
Let’s say you are making an App. It may be a web app, a micro service, or an smartphone app. Now say your app needs to make a lot of asynchronous API calls to pull data from remove database/app servers. First you tried first version of your Asynchronous non-blocking model using only pure threads.
At some time of your app evolution, you found that you are having too many such background threads and you fear of overflowing memories, wasting thread time slices. And there came some kind of thread pool manager like Worker Executor Service in Java to control number of active threads. Let’s say you limited maximum number of active threads for pulling data is 100. It works GREAT! But now you see your servers are costing your a lot of money sleeping most of the time.
So, your micro-service or app architecture is blocking the OS to gain full potential of your infrastructure! In fact, it’s your asynchronous threads who are blocking!
Now, what does non-blocking mean? Can you decouple your data pulling feature from the thread? Yes, you can, and that’s what non-blocking is. Read message driven and event driven architectures!