Loading...
System Design and AI Engineering, by Roni Das. 974 interactive lessons.
Start LearningThe short answerSynchronous code does one thing at a time and waits for each step to finish before starting the next, while asynchronous code can start a slow step, such as a network call, and do other work while it waits, so async only makes a program faster when it spends its time waiting and those waits can overlap.
Blocking, one step at a time
the single queue at the counter
Non-blocking, start now, collect later
order, then sit down until your number is called
Read across a row to compare one thing. Every word that may be new is explained just below the table.
| Aspect | Synchronous | Asynchronous |
|---|---|---|
| How steps run | One after another. Step 2 waits for step 1. | Slow steps are started and left running; the program moves on. |
| During a slow network call | The thread sits idle until the answer comes back. | The event loop runs other tasks until the answer comes back. |
| Total time for N independent waits | About the sum of all N waits. Ours: 5.15 s for 50 x 100 ms. | About the longest single wait, if started together. Ours: 0.16 s. |
| CPU-heavy work | Runs at full speed on one core. | No faster. Our 50 hash jobs took 0.26 s either way. |
| Reading the code | Top to bottom, like a recipe. | Needs async/await, and you must think about what runs when. |
| Errors | Raised at the line that failed. | Raised when you await the task. Forgetting to await can hide them. |
| Typical tools | requests, urllib, plain function calls. | Python asyncio and httpx, JavaScript Promises, Node.js. |
| Best for | Scripts, steps that depend on each other, CPU work. | Servers with many clients, fan-out to many APIs, chat, streaming. |
Real situations, and the pick we would make in each one.
Each connection spends most of its life waiting on the network. An event loop can hold many of them with very few threads.
The 50 calls do not depend on each other. Start them together and the page waits about as long as the slowest supplier.
Each step needs the result of the one before it. Running them in order is correct, and async would not make it faster.
This is CPU work. Async cannot overlap computing; use several processes so more CPU cores share the job.
There is nothing to overlap. Plain synchronous code is shorter and easier to debug.
Answer the user synchronously, and hand the email to a background queue that sends it asynchronously.
we ran this, here is what happened
Many explanations stop at "async is faster". We wanted to know when it is faster, and when it is not.
We ran a tiny web server on one laptop that waits 100 milliseconds before answering every request, like a slow database or API. Then a client asked it 50 times: synchronously one by one, with async code but awaiting each call before the next, and with async code that starts all 50 together.
As a control we also timed 50 pieces of pure computing (hashing), with no waiting at all, done in order and through asyncio. We ran the whole script three times.
Where it ran: Apple M4, macOS 15.6, Python 3.13.15, httpx 0.28.1, a local asyncio HTTP server on 127.0.0.1 that sleeps 100 ms per request. Three full runs on 4 October 2026.
def sync_sequential() -> dict:
t0 = time.perf_counter()
for _ in range(CALLS):
with urllib.request.urlopen(URL) as r: # blocks here until the answer arrives
r.read()
return {"seconds": round(time.perf_counter() - t0, 3)}
async def async_one_by_one() -> dict:
async with httpx.AsyncClient() as client:
t0 = time.perf_counter()
for _ in range(CALLS):
await client.get(URL) # async code, but each await finishes before the next starts
return {"seconds": round(time.perf_counter() - t0, 3)}
async def async_gather() -> dict:
limits = httpx.Limits(max_connections=CALLS)
async with httpx.AsyncClient(limits=limits) as client:
t0 = time.perf_counter()
replies = await asyncio.gather(*(client.get(URL) for _ in range(CALLS)))
return {"seconds": round(time.perf_counter() - t0, 3), "all_200": all(r.status_code == 200 for r in replies)}{
"machine": "arm64, macOS 15.6, Python 3.13.15, httpx 0.28.1",
"calls": 50,
"server_delay_seconds": 0.1,
"best_possible_sequential_seconds": 5.0,
"sync_sequential": {
"seconds": 5.153
},
"async_one_by_one": {
"seconds": 5.233
},
"async_gather": {
"seconds": 0.164,
"all_200": true
},
"cpu_control": {
"pieces": 50,
"sync_seconds": 0.259,
"async_gather_seconds": 0.256
},
"speedup_gather_vs_sync": 31.4
}| What we measured | Synchronous | Asynchronous |
|---|---|---|
| 50 calls, 100 ms each (3 runs)30x to 39x faster | 5.15 to 5.17 s, one by one | 0.13 to 0.17 s, gathered |
| Async code, but awaited one at a timeno gain at all | 5.15 to 5.17 s | 5.21 to 5.23 s |
| 50 CPU jobs (hashing, no waiting)no real gain | 0.26 to 0.29 s | 0.25 to 0.27 s |
| All 50 answers came back OKevery gathered reply was HTTP 200 | yes | yes |
What this shows
Async was 30 to 39 times faster, but only in one of its two forms. Code that used async and await yet waited for each call before starting the next took just as long as plain synchronous code, slightly longer in fact. The speed came from starting the waits together, not from the keyword. And for computing with no waiting, async changed nothing.
What this test does not show: One machine and one artificial 100 ms delay. Real APIs vary, can limit how many calls you make at once, and can slow down when you send many together. Threads are another way to overlap waits; we did not test them here. The script is scripts/labs/compare/sync_vs_async.py in our repository.
"Async makes code faster."
Only waiting can overlap. In our test, 50 hash jobs took 0.26 s with or without asyncio. For CPU work, use more processes or cores.
Writing await inside a loop and expecting a speed-up.
That still runs one call at a time: 5.23 s in our run. Start the tasks first, then wait for all of them (asyncio.gather, Promise.all).
Calling a blocking library from async code.
A blocking call such as requests.get or time.sleep inside an async function freezes the whole event loop. Use an async library (httpx, aiohttp) or run it in a thread.
Firing 10,000 calls at once.
The other side may refuse or slow down. Limit how many run together, for example with a semaphore or the client's connection limit.
Confusing asynchronous with parallel.
Async means many tasks are in progress and take turns while they wait. Parallel means several run at the very same instant on different cores. Our event loop used one thread.
Synchronous steps run in order, and each waits for the one before it to finish. Asynchronous steps can be started and left running, so the program can do other work while it waits for an answer.
A page that asks 50 suppliers for prices at the same time and shows the results when they arrive. In our lab, starting 50 slow calls together took 0.16 seconds instead of 5.15.
Not in programming. In education, an asynchronous course means you study at your own time instead of joining a live class. In programming, asynchronous means a task can run while the program does something else. This page is about the programming meaning.
JavaScript runs your code on one thread, one step at a time, but browsers and Node.js give it asynchronous tools (callbacks, Promises, async and await) so a slow network or disk call does not block everything else.
Plain Python is synchronous. The asyncio library and the async and await keywords, added in Python 3.5 by PEP 492, let you write asynchronous code. You also need async libraries, such as httpx, for the slow calls themselves.
When the steps depend on each other, when the work is mostly computing, or when the program is small. In those cases async adds complexity and, as our CPU control showed, no speed.
From the System Design course, in the order we would read them.
Primary sources only: standards, vendor docs and our own runs. Each one shows its date and the day we opened it.
Synchronous vs Asynchronous is one row in a much bigger table. Our System Design course has 770 lessons on networks, databases, caching, scaling, messaging, security and reliability, each drawn step by step, so you can explain the trade-off in an interview and pick right at work. 18 lessons are free to read, with no card needed.
the hands-on parts are real runs, like this one
course 1
From absolute beginner to principal engineer, drawn step by step.