Almost everything a program does involves asking something else to do work and waiting for an answer: reading a file, querying a database, calling another service over the network. The key design question is what the caller does while that work is happening. Does it stop and wait, or does it carry on with other things?
That single choice — synchronous versus asynchronous — shapes how fast your system feels, how much it can handle at once, and how complicated it is to write and debug.
Synchronous: stop and wait
A synchronous call is blocking: the caller sends a request and then does nothing else until the reply comes back. The line of code that makes the call simply doesn't return until the work is finished, and only then does the next line run.
Think of phoning a colleague and staying on the line in silence until they look something up. You can't start your next task while you hold the receiver — you're blocked. In code it looks like const user = getUser(id): the moment you write that, you're promising to wait right there for the answer before touching user.
CallerSends a request and blocks — it does nothing else until the reply returns.
The great virtue of synchronous code is that it is simple to reason about. Steps happen strictly in order, top to bottom; when a line finishes you know its result is ready, and errors surface right where the call was made. There is one path through the code and one place to look when something goes wrong.
The cost is that waiting wastes time. While the caller is blocked it does no useful work, even though the machine is perfectly capable of doing something else. Just as bad, it couples the caller's availability to the callee's: if the thing you called is slow or down, you are slow or stuck too, because you've chosen to wait for it.
Blocking and synchronous describe the same idea from two angles. Synchronous says the steps are in lockstep — the result is ready by the time the call returns. Blocking says the caller is parked and can do nothing while it waits. A synchronous call is a blocking call; the words are used almost interchangeably.
Asynchronous: fire it off and continue
An asynchronous call is non-blocking: the caller sends the request and immediately continues with other work. It does not sit and wait for the reply. Instead, the result is delivered later — when it's actually ready — by one of a few mechanisms.
The common ways the answer comes back are a callback (you hand over a function to be run once the work is done), a promise or future (a placeholder object that will eventually hold the result, which you can wait on or react to later), or a message queue (you drop the request onto a queue and a separate worker processes it and reports back through another message).
QueueHolds the handed-off work so the caller can move on immediately.- WorkerProcesses the work later and reports back via a callback.
Because the caller never idles, asynchronous work improves throughput: the same thread or process can kick off many requests and handle whichever results arrive first, instead of burning time waiting on each one in turn. It also improves resilience — when you communicate through a queue, the caller and the worker don't have to be up at the same instant. If the worker is briefly down, requests wait safely in the queue and get processed when it recovers, rather than failing on the spot.
The price is complexity. The result isn't ready at the line that asked for it, so you have to handle a future that hasn't resolved yet. Callbacks can nest into hard-to-follow chains, ordering is no longer guaranteed because responses can arrive in any sequence, and partial failure becomes a real concern — some of the work you fired off may succeed while other parts fail, and you have to reason about every combination.
Async is not the same as parallel
It's easy to assume asynchronous means "running at the same time," but they are different ideas. Asynchronous is about not waiting — the caller is free to do other things while a request is in flight. Parallel is about literally executing multiple things simultaneously, which requires multiple cores or machines.
A single thread can be highly asynchronous with no parallelism at all: it starts a network request, sets it aside, does other work, and picks up the response when it lands — all on one core, by never blocking. Conversely, you can run blocking code on many threads to get parallelism without anything being asynchronous. Async manages waiting efficiently; parallelism manages doing more at once.
Reach for synchronous when the next step truly needs the answer and the call is fast and local — validating input, reading a value you're about to use, simple request/response. The clarity is worth it. Reach for asynchronous when the work is slow, remote, or independent — I/O over the network, sending email, generating a report, or anything where blocking would waste time or chain your uptime to someone else's. When in doubt, keep the simple synchronous version until waiting actually becomes a problem.
Neither model is universally better. Synchronous code trades efficiency for simplicity; asynchronous code trades simplicity for throughput and resilience. The skill is matching the tool to the call: keep the things that must happen in order synchronous and obvious, and push the slow, independent, failure-prone work off the critical path with asynchronous techniques like callbacks, futures, and message queues.