FastAPI and the event loop

FastAPI is an ASGI application. It does not own the event loop — Uvicorn does — and your handlers are coroutines scheduled on it. Everything that surprises people about FastAPI performance follows from that one fact.

def and async def are routed differently

@app.get("/a")
async def a():
    # runs ON the event loop
    return await db.fetch(...)

@app.get("/b")
def b():
    # runs in a THREAD POOL
    return blocking_db.fetch(...)

FastAPI inspects the handler. A coroutine function runs on the loop; a plain function is handed to a worker thread so it cannot stall everything else.

The dangerous combination is the third one — blocking code inside async def, which nothing rescues:

@app.get("/c")
async def c():
    # stalls every request
    return requests.get(url).json()

One slow call there freezes the whole worker, including handlers that touch nothing. The symptom is p99 rising on every endpoint at once, which is the same signature as Debugging and introspecting async code.

Gotcha: the thread pool is bounded (40 by default via AnyIO). Enough concurrent def handlers and requests queue for a thread — latency rises with no CPU pressure and no slow query to point at.

If you must call blocking code from an async handler, hand it to a thread explicitly:

row = await anyio.to_thread.run_sync(blocking_db.fetch, key)

Depends is a graph, resolved per request

async def get_session() -> AsyncIterator[AsyncSession]:
    async with SessionLocal() as s:
        # teardown after the response
        yield s

async def current_user(
    s: Annotated[AsyncSession, Depends(get_session)],
    token: Annotated[str, Depends(oauth2)],
) -> User:
    return await s.get(User, decode(token).sub)

@app.get("/me")
async def me(user: Annotated[User, Depends(current_user)]):
    return user

Two properties worth naming. Dependencies compose — current_user requests get_session and FastAPI resolves the graph. And a dependency requested twice in one request is called once, its result cached for that request, so get_session above yields the same session to everything downstream.

That caching is why Depends is the right place for a database session and the wrong place for anything that must run twice.

# Opt out when you genuinely want a fresh call.
Depends(make_nonce, use_cache=False)

Dependencies obey the same def/async def rule as handlers, so a synchronous dependency also goes to the thread pool.

Where the concurrency actually comes from

Async does not make one request faster. It makes a waiting request cheap, so one worker serves many. The corollary: it buys nothing for CPU-bound work — that needs more processes, not more coroutines.

Inside a single handler, concurrency is explicit:

async with asyncio.TaskGroup() as tg:
    a = tg.create_task(prices.get(sku))
    b = tg.create_task(stock.get(sku))
return {"price": a.result(), "stock": b.result()}

Total latency is the slower call rather than the sum, and a failure in either cancels the other. See TaskGroup and Structured Concurrency.