FastAPI

FastAPI is Starlette plus Pydantic plus dependency injection plus auto-generated OpenAPI. That stack gives you typed request/response validation, async I/O on top of uvicorn/uvloop, and free Swagger UI at /docs. At Binocs we replaced a Flask service with FastAPI and cut p95 latency from 320ms to 90ms on the same hardware.

The mental model

FastAPI handlers are coroutines run on an asyncio event loop. The event loop is single-threaded. When you await a network call, the loop suspends your coroutine and runs another. When the I/O completes, your coroutine resumes. Throughput comes from overlapping I/O, not from CPU parallelism.

What I actually built

• REST endpoints for the compliance dashboard, validated by Pydantic models that doubled as the OpenAPI schema and the TypeScript types via codegen.
• Dependency injection for the DB session, the current user, and the tenant context. One Depends(get_db) and the session was scoped to the request.
• Background tasks with BackgroundTasks for fire-and-forget notifications, and Celery for anything that had to retry or persist.
• Lifespan handlers to warm the Redis pool and the SQLAlchemy connection pool before serving traffic.

The one rule

If you use async def, every I/O call inside must be awaitable. Use httpx not requests. Use asyncpg or psycopg3 async mode, not psycopg2. Use aiofiles not open(). The moment you put a blocking call inside an async handler, you stall the whole event loop and every concurrent request waits.

If you cannot avoid a blocking library, FastAPI will run sync def handlers in a threadpool automatically. Use that escape hatch deliberately. Do not mix.

Performance numbers

A single uvicorn worker on 1 vCPU comfortably does 8000 req/s on a hello-world handler, 2000 req/s on a Pydantic-validated handler with a Postgres query. We ran 4 workers per pod on EKS, behind an ALB.

The CPU bottleneck in production is Pydantic v1 validation. Pydantic v2 (Rust-based core) is 5x to 50x faster. Upgrade.