Search Topics

Search across all FastAPI topics

GitHub

Under the Hood

3 topics

Peek behind the curtain — how FastAPI's event loop, ASGI server, and process managers work together to handle thousands of requests.

Tip

FastAPI is built on ASGI (Asynchronous Server Gateway Interface), which is why it can handle thousands of concurrent connections with a single process. No threads needed.

How a Request Travels Through the Stack

Step 1: Client Request

A browser, mobile app, or another service sends an HTTP request to your server.

The Event Loop
How Python's event loop juggles multiple requests on a single thread — and why async matters.
ASGI vs WSGI
The two Python server standards. Why FastAPI chose the async one, and what that means for you.
Uvicorn & Gunicorn
What each process does, when to use which, and how they work together in production.

Try It: Server Architecture Comparison

These are the patterns that trip up developers most often. Switch between Wrong and Fixed to compare the code side by side.

1
Blocking the event loop with sync code
Using time.sleep() or requests library in async handlers
Don't do this
main.py
import time
import requests

@app.get("/data")
async def get_data():
    time.sleep(5)  # Blocks the ENTIRE event loop!
    resp = requests.get("https://api.example.com")
    return resp.json()
In an async handler, time.sleep() and the requests library block the entire event loop, freezing ALL concurrent requests. Use asyncio.sleep() and httpx instead — they yield control back to the event loop while waiting.
2
Running FastAPI with a WSGI server
Using gunicorn without the Uvicorn worker class
Don't do this
terminal
# This runs FastAPI as WSGI — no async!
gunicorn main:app

# Or using waitress (WSGI server)
waitress-serve main:app
FastAPI is an ASGI framework. Running it with a WSGI server like raw gunicorn or waitress means async doesn't work — your await calls become blocking. Always use Uvicorn directly or Gunicorn with the UvicornWorker class.