Why is my FastAPI app slow even though the routes are async?

Almost always because something inside an async route is blocking the event loop. The asyncio loop is single-threaded, so one synchronous database query, a requests.get() call, or a time.sleep() freezes every concurrent request on that worker. Swap in async libraries (httpx instead of requests, asyncpg or async SQLAlchemy instead of psycopg2, aiofiles instead of open) and push CPU-bound work into a thread or process pool.

Should I use async def or plain def for a FastAPI route?

Use async def only if the handler actually awaits async I/O. If the route calls only synchronous code, declare it as plain def and FastAPI will run it in a thread pool automatically, which keeps the event loop free. Declaring a sync-only handler as async def is how you accidentally block every other in-flight request on that worker.

Celery, ARQ, or Dramatiq for background jobs in Python?

ARQ for most new FastAPI projects, Celery when you need its workflow primitives, Dramatiq when you want a cleaner Celery. ARQ is purpose-built for async Python and Redis, and its native asyncio workers slot cleanly into an async FastAPI app. Celery is the most mature and has chains, chords, groups, a beat scheduler, and broad broker support, but its config surface is large and its async story needs asgiref.

How should I run FastAPI in production?

Gunicorn as the process manager with uvicorn workers. Gunicorn handles worker lifecycle, graceful shutdown, and SIGTERM. Uvicorn provides the ASGI event loop. Start at roughly one worker per CPU core, since each async worker handles concurrency inside its own event loop, and measure under real load before tuning further. In Docker, install dependencies with uv sync --frozen so the build matches your uv.lock exactly.

Modern Python Backends: FastAPI, Async, Production

For years, Python was the "good enough" backend choice. Fine for prototypes. Not serious for production. The conventional wisdom was: if you care about performance, use Go. If you care about type safety, use Go. If you want async that actually works, use Go. That's changed. FastAPI, Pydantic v2, a properly understood async model, and the uv ecosystem have made Python genuinely competitive for backend work, and it's not just because of AI.

That said, I want to be honest about the tradeoffs. Python still loses on raw throughput compared to Go or Rust. It's not going to win a benchmark contest (the Go-or-Rust tradeoff for the cases where Python does lose is what we covered in Rust vs Go). What it wins is iteration speed, hiring ease, and a tooling ecosystem that has legitimately caught up. For most teams, that trade is worth making. Here's what modern Python backend development actually looks like.

FastAPI Deep Dive: What Makes It Different

FastAPI is built on Starlette (the ASGI framework) and Pydantic (the data validation library). Its key innovation is using Python type annotations to drive request parsing, response serialization, and OpenAPI documentation generation simultaneously from a single source of truth. That sounds like a small thing, but in practice it eliminates a large class of bugs that come from keeping multiple representations of the same schema in sync.

Pydantic v2 Models

Pydantic v2 rewrote its core in Rust, delivering 5-50x validation performance improvements over v1. Define your models with strict type annotations and validators, and FastAPI automatically validates incoming request bodies, path parameters, and query strings against them.

from pydantic import BaseModel, Field, field_validator, model_validator
from typing import Annotated
from datetime import datetime

class CreateOrderRequest(BaseModel):
    model_config = {"str_strip_whitespace": True, "str_min_length": 1}

    customer_id: Annotated[int, Field(gt=0)]
    items: Annotated[list[OrderItem], Field(min_length=1, max_length=100)]
    shipping_address: ShippingAddress
    coupon_code: str | None = None

    @field_validator("coupon_code")
    @classmethod
    def normalize_coupon(cls, v: str | None) -> str | None:
        return v.upper().strip() if v else None

    @model_validator(mode="after")
    def check_item_availability(self) -> "CreateOrderRequest":
        # Cross-field validation after individual field validation
        if len(self.items) > 50 and self.coupon_code is None:
            raise ValueError("Bulk orders require a coupon code")
        return self

Dependency Injection

FastAPI's dependency injection system is its most underappreciated feature, and most people don't use it properly. Dependencies are plain Python callables (functions or classes) declared in route signatures. FastAPI resolves them, caches results within a request scope, and handles cleanup via context managers. This keeps route handlers thin and makes business logic highly testable. The teams I've seen using FastAPI well treat dependency injection as the primary architectural pattern, not an afterthought.

from fastapi import Depends, HTTPException, status
from sqlalchemy.ext.asyncio import AsyncSession

async def get_db_session(
    session_factory: AsyncSessionFactory = Depends(get_session_factory)
) -> AsyncGenerator[AsyncSession, None]:
    async with session_factory() as session:
        try:
            yield session
            await session.commit()
        except Exception:
            await session.rollback()
            raise

async def get_current_user(
    token: str = Depends(oauth2_scheme),
    db: AsyncSession = Depends(get_db_session),
) -> User:
    credentials_exception = HTTPException(
        status_code=status.HTTP_401_UNAUTHORIZED,
        detail="Could not validate credentials",
        headers={"WWW-Authenticate": "Bearer"},
    )
    try:
        payload = jwt.decode(token, settings.SECRET_KEY, algorithms=["HS256"])
        user_id: int = payload.get("sub")
    except JWTError:
        raise credentials_exception

    user = await UserRepository(db).get_by_id(user_id)
    if user is None or not user.is_active:
        raise credentials_exception
    return user

@router.get("/orders", response_model=list[OrderResponse])
async def list_orders(
    pagination: PaginationParams = Depends(),
    current_user: User = Depends(get_current_user),
    db: AsyncSession = Depends(get_db_session),
) -> list[Order]:
    return await OrderRepository(db).list_by_user(current_user.id, pagination)

Async Python Done Correctly

Async Python is powerful and frequently misused. The asyncio event loop is single-threaded: a single blocking call (a synchronous database query, a requests.get() call, a time.sleep()) freezes the entire event loop and blocks all concurrent requests. This is the most common source of production performance problems in FastAPI applications, and it's not always obvious when it's happening.

The rules: every I/O operation must use an async library (httpx instead of requests, asyncpg or async SQLAlchemy instead of psycopg2, aiofiles instead of the built-in open()). CPU-bound operations must be offloaded to a thread or process pool using asyncio.to_thread() or loop.run_in_executor(). Route handlers that call only sync code should be declared as plain def (not async def); FastAPI will run them in a thread pool automatically, avoiding event loop blocking.

import asyncio
from concurrent.futures import ProcessPoolExecutor

# CPU-bound work (image processing, PDF generation, ML inference)
# must be offloaded to avoid blocking the event loop
_process_pool = ProcessPoolExecutor(max_workers=4)

async def process_image_upload(file_bytes: bytes) -> str:
    loop = asyncio.get_running_loop()
    # run_in_executor offloads to process pool, freeing the event loop
    result = await loop.run_in_executor(
        _process_pool,
        _sync_image_processing_fn,  # pure function, picklable
        file_bytes,
    )
    return result

# Concurrent I/O: use asyncio.gather, not sequential awaits
async def enrich_order(order_id: int, db: AsyncSession) -> EnrichedOrder:
    order, customer, inventory = await asyncio.gather(
        OrderRepository(db).get(order_id),
        CustomerRepository(db).get_for_order(order_id),
        InventoryService.check_availability(order_id),
    )
    return EnrichedOrder(order=order, customer=customer, inventory=inventory)

SQLAlchemy 2.0 Async Patterns

SQLAlchemy 2.0's async engine is production-ready and handles connection pooling, transaction management, and relationship loading correctly when used properly. The key pattern: keep sessions short-lived, use explicit eager loading to avoid N+1 queries, and never pass session objects across task boundaries.

from sqlalchemy import select, func
from sqlalchemy.orm import selectinload, joinedload

class OrderRepository:
    def __init__(self, session: AsyncSession) -> None:
        self._session = session

    async def get_with_items(self, order_id: int) -> Order | None:
        stmt = (
            select(Order)
            .where(Order.id == order_id)
            .options(
                selectinload(Order.items).selectinload(OrderItem.product),
                joinedload(Order.customer),
            )
        )
        result = await self._session.execute(stmt)
        return result.scalar_one_or_none()

    async def list_paginated(
        self, user_id: int, offset: int, limit: int
    ) -> tuple[list[Order], int]:
        count_stmt = select(func.count()).where(Order.user_id == user_id)
        orders_stmt = (
            select(Order)
            .where(Order.user_id == user_id)
            .order_by(Order.created_at.desc())
            .offset(offset)
            .limit(limit)
        )
        count, orders = await asyncio.gather(
            self._session.scalar(count_stmt),
            self._session.scalars(orders_stmt),
        )
        return list(orders), count or 0

Task Queues: Celery vs ARQ vs Dramatiq

Background task processing is essential for any production backend. Three libraries dominate the Python space, each with a distinct design philosophy.

Celery is the most mature and feature-rich: complex workflows (chains, chords, groups), canvas primitives, beat scheduler for cron jobs, and broad broker support (Redis, RabbitMQ, SQS). The tradeoff is complexity. Celery's configuration surface is large, and its async support requires extra care (Celery workers are synchronous by default; async tasks need asgiref integration).

ARQ is purpose-built for async Python and Redis. Workers are native asyncio, so they integrate cleanly with the rest of an async FastAPI application. ARQ is simpler than Celery and appropriate for straightforward queuing needs (job definition, priority queues, job scheduling, retry logic). If you don't need Celery's workflow primitives, ARQ is the better choice for FastAPI applications. This is what I'd reach for on a new project.

Dramatiq sits between the two: a cleaner API than Celery, synchronous workers with actor-based concurrency, and good reliability guarantees. Consider Dramatiq if you're migrating from Celery and want a simpler alternative without going full-async.

Structured Logging and Observability

Structured logging means emitting JSON log lines with consistent fields rather than free-form strings, making logs queryable and parseable by log aggregation platforms (Datadog, Splunk, Loki). structlog is the standard library for this in Python, and it's excellent.

import structlog
from structlog.contextvars import bind_contextvars, clear_contextvars

logger = structlog.get_logger()

# Middleware to bind request-scoped context to all log calls
class RequestContextMiddleware(BaseHTTPMiddleware):
    async def dispatch(self, request: Request, call_next):
        clear_contextvars()
        bind_contextvars(
            request_id=request.headers.get("X-Request-ID", str(uuid4())),
            method=request.method,
            path=request.url.path,
        )
        start = time.monotonic()
        response = await call_next(request)
        bind_contextvars(
            status_code=response.status_code,
            duration_ms=round((time.monotonic() - start) * 1000, 2),
        )
        logger.info("request_completed")
        return response

# In your service layer : all context is automatically included
async def create_order(request: CreateOrderRequest) -> Order:
    logger.info("order_creation_started", item_count=len(request.items))
    order = await _process_order(request)
    logger.info("order_created", order_id=order.id, total_cents=order.total_cents)
    return order

Testing FastAPI Applications

FastAPI applications are highly testable. Use pytest-asyncio for async test functions, httpx.AsyncClient with ASGITransport as the test HTTP client when you want the test to run inside the same event loop as your app, and factory_boy for fixture generation. The synchronous TestClient still works fine, it just drives your async app through a sync bridge, which makes event-loop-sensitive bugs harder to reproduce in a test.

import pytest
import pytest_asyncio
from httpx import AsyncClient, ASGITransport
from sqlalchemy.ext.asyncio import create_async_engine, AsyncSession

@pytest_asyncio.fixture
async def db_session():
    engine = create_async_engine("sqlite+aiosqlite:///:memory:")
    async with engine.begin() as conn:
        await conn.run_sync(Base.metadata.create_all)
    async with AsyncSession(engine) as session:
        yield session

@pytest_asyncio.fixture
async def client(db_session: AsyncSession):
    app.dependency_overrides[get_db_session] = lambda: db_session
    async with AsyncClient(
        transport=ASGITransport(app=app), base_url="http://test"
    ) as ac:
        yield ac
    app.dependency_overrides.clear()

@pytest.mark.asyncio
async def test_create_order(client: AsyncClient, db_session: AsyncSession):
    user = await UserFactory.create_async(session=db_session)
    token = create_access_token(user.id)
    payload = CreateOrderRequestFactory.build()

    response = await client.post(
        "/orders",
        json=payload.model_dump(),
        headers={"Authorization": f"Bearer {token}"},
    )

    assert response.status_code == 201
    data = response.json()
    assert data["customer_id"] == user.id

Deployment: uvicorn, Gunicorn, and uv

For production deployment, the recommended configuration is Gunicorn as the process manager with uvicorn workers. Gunicorn handles worker lifecycle (restarts, graceful shutdown, SIGTERM handling) while uvicorn provides the ASGI event loop. On worker count: ignore the old 2 * CPU_cores + 1rule you'll see repeated everywhere. That formula comes from Gunicorn's synchronous workers, where each worker handles one request at a time. An async uvicorn worker multiplexes thousands of connections on its own event loop, so roughly one worker per core is the right starting point, and you tune from there against real load.

# Dockerfile
FROM python:3.13-slim

COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /usr/local/bin/

WORKDIR /app
COPY pyproject.toml uv.lock ./
RUN uv sync --frozen --no-dev

COPY src/ ./src/

HEALTHCHECK --interval=30s --timeout=5s --start-period=10s     CMD curl -f http://localhost:8000/health || exit 1

CMD ["uv", "run", "gunicorn", "src.main:app",
     "--workers", "4",
     "--worker-class", "uvicorn.workers.UvicornWorker",
     "--bind", "0.0.0.0:8000",
     "--timeout", "30",
     "--graceful-timeout", "30",
     "--access-logfile", "-"]

uv has replaced pip, pip-tools, and pyenv in modern Python projects. Its lockfile (uv.lock) provides reproducible builds with sub-second resolution times. Use uv sync --frozen in CI and Docker to install exactly the locked versions. Use uv add and uv remove to manage dependencies; both update pyproject.toml and uv.lock atomically. The AI wave has made Python hiring easier and the tooling better, which changes the build-vs-buy calculus for startups. You can now hire strong Python engineers who are also comfortable with the ML/data ecosystem, which is a genuinely useful combination.

The teams shipping the most reliable Python backends aren't using Python differently. They're using it more carefully. The async primitives, type system, and tooling have all matured. The discipline of applying them consistently is what separates production systems from projects that work great in development.

Python backend development has genuinely grown up. FastAPI's ergonomics, Pydantic v2's performance, and the async ecosystem's maturity have closed most of the gap with Go and Node.js for API workloads, while retaining the rapid iteration speed that makes Python valuable. The patterns in this guide: thin route handlers, dependency injection, explicit async discipline, structured observability, and reproducible packaging, are what a production Python backend looks like now.

Modern Python Backend Development: FastAPI, Async, and Production Patterns

Key takeaways