Async vs sync decision in FastAPI - Visual Side-by-Side Comparison

Concept Flow - Async vs sync decision

Request arrives

↓

Is handler async?

No→Run sync handler

↓

Process request

↓

Run async handler

↓

Send response

↓

Await async tasks

↓

End

↓

Send response

↓

End

When a request comes, FastAPI checks if the handler is async or sync. It runs async handlers with await, sync handlers directly, then sends the response.

Execution Sample

FastAPI

from fastapi import FastAPI
app = FastAPI()

@app.get("/sync")
def sync_handler():
    return {"message": "sync response"}

@app.get("/async")
async def async_handler():
    return {"message": "async response"}

Defines two routes: one sync handler and one async handler, showing how FastAPI handles each.

Execution Table

Step	Request Path	Handler Type	Action	Response Sent
1	/sync	sync	Call sync_handler directly	{"message": "sync response"}
2	/async	async	Await async_handler coroutine	{"message": "async response"}
3	/sync	sync	Call sync_handler directly	{"message": "sync response"}
4	/async	async	Await async_handler coroutine	{"message": "async response"}
5	-	-	No more requests	-

💡 Execution stops when no more requests are received.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
request_path	-	/sync	/async	/sync	/async	-
handler_type	-	sync	async	sync	async	-
response	-	{"message": "sync response"}	{"message": "async response"}	{"message": "sync response"}	{"message": "async response"}	-

Key Moments - 2 Insights

Why does FastAPI await async handlers but call sync handlers directly?

Because async handlers return coroutines that must be awaited to run, while sync handlers run immediately. See execution_table steps 1 and 2.

Can a sync handler use await inside it?

No, sync handlers cannot use await. They run like normal functions. Async handlers can use await. This is shown by the different actions in execution_table.

Visual Quiz - 3 Questions

Look at the execution_table, what is the response sent at Step 2?

A No response sent

B {"message": "async response"}

C {"message": "sync response"}

D Error

💡 Hint

Check the Response Sent column at Step 2 in execution_table.

At which step does FastAPI await the async handler?

A Step 2

B Step 1

C Step 3

D Step 4

💡 Hint

Look at the Action column in execution_table for when 'Await async_handler coroutine' happens.

If the /sync handler was changed to async, what would change in the execution_table?

A No change, it would still be sync

B The response would be different

C The handler_type would be 'async' and action would be 'Await async_handler coroutine' for /sync requests

D FastAPI would throw an error

💡 Hint

Refer to variable_tracker and execution_table showing handler_type and action per request path.

Concept Snapshot

FastAPI decides handler type by function definition:
- sync def: called directly
- async def: awaited
Async handlers allow non-blocking operations.
Sync handlers run immediately.
Use async for I/O-bound tasks.
Use sync for simple, fast operations.

Full Transcript

When FastAPI receives a request, it checks if the handler function is async or sync. If sync, it calls the function directly and returns the response. If async, it awaits the coroutine to complete before sending the response. This allows async handlers to perform non-blocking operations like waiting for database calls without blocking the server. Sync handlers run immediately and block until done. The execution table shows requests to /sync and /async paths, with FastAPI calling or awaiting handlers accordingly. Variables track the request path, handler type, and response sent at each step. Key moments clarify why async handlers must be awaited and why sync handlers cannot use await. The visual quiz tests understanding of these execution steps. This helps beginners see how FastAPI manages async vs sync decisions in real time.