Unit 01.03: Sync and async, and the choice you are making

async def helps when the handler waits. Used wrongly it makes everything slower for everyone.

Concurrency, not parallelism

Ten waits of ten milliseconds, run concurrently and one at a time.

The code times both.

import asyncio, time

async def async_io(n):
    await asyncio.gather(*(asyncio.sleep(0.01) for _ in range(n)))

def sync_io(n):
    for _ in range(n):
        time.sleep(0.01)

n = 10
start = time.perf_counter()
asyncio.run(async_io(n))
async_ms = (time.perf_counter() - start) * 1000

start = time.perf_counter()
sync_io(n)
sync_ms = (time.perf_counter() - start) * 1000

print(f"{n} waits of 10ms each")
print(f"  async, concurrently : {async_ms:>6.0f} ms")
print(f"  sync, one at a time : {sync_ms:>6.0f} ms")

print("""
`async def` helps when the handler WAITS -- on a database, an HTTP call, a
model API. It does nothing for CPU work, and blocking inside an async handler
stalls every other request on that worker.

If a library gives you no async client, use `def` and let FastAPI run it in a
threadpool. A blocking call inside `async def` is the classic mistake.
""")

The concurrent version takes about as long as one wait; the sequential one takes the sum. That is the entire benefit, and it only applies while the handler is genuinely waiting on something external.

For CPU work async does nothing. Worse, a blocking call inside an async def handler stalls the event loop - every other request on that worker waits, including ones touching a completely different endpoint.

The mistake this prevents

The mistake is declaring every handler async def because it looks modern, then calling a synchronous database driver inside it. Declare it def instead and FastAPI runs it in a threadpool, leaving the loop free.

Takeaway

Use async def when you await something. If a library has no async client, use def - a blocking call inside async def stalls every other request on that worker.

Mark complete